I was trying to figure out where Android devices keep their keystore file for trusted Certificate Authorities (CAs) so I could audit mine. One of the first answers Google brought me was advice from Motorola.
They described exactly what I was thinking about:
"add and remove additional root certificates including self-signed ones. So companies, which release their own root certificates for their employees are able to install them on Motorola phones."
Great, some advice on adjusting who I trust!
Wait!!!!
"Copy the certificate (.p12) file to the memory card. (There is no need to create a unique folder)"
Umm, but a PKCS12 file has to contain the certificate AND the associated private key. Am I expected to just ask the CA operator to had that over? I'm sure they'll be emailing that to me at any moment.
I did a bit more poking around and Motorola may not be the only one to blame. It appears that a few Android implementations are only aware of one certificate format.
Dear Motorola, please do not engage in crypto or crypto advice unless you have a clue. When trusting a CA or a cert explicitly, the file formats are PEM and DER.
I know this topic is boring, but really, if you can't do PKI and basic crypto and you are in any form of IT, your days of employment are numbered.
While my new blog may seem mean spirited, it comes from a place of love. I am fed up with amateurs, posers, and "journalists" who have no business trying to influence opinion on security matters. The fundamentals of infoSec have not changed much in 10 years, yet CIO Magazine, Security Hourly, or whatever else would have you believe there is a silver bullet or security "Just Got Easy", or some crap like that.
Sunday, October 28, 2012
Saturday, October 13, 2012
Larry Seltzer have you no shame?
Before we get started, Google this phrase "Advances in attacks on network security over the last few years have led to many"
Look, there's a fairly recent white paper from April of 2012 called, "Spoofing Server-Server Communication How You Can Prevent It"
Never mind, there it is from April of 2011.
No! WAIT! There it is from Decemnber of 2009.
This horrible piece of work came to me by email. I can't blame Symantec or VeriSign for putting it in my face, as it was sent by IDG, but pulling this work of stellar suck out once a year is sad and pathetic.
This is another case where idiots in Marketing get the bright idea to have a "journalist" "report" on something in the news that they think can sell product. I use the quotes in the most condescending manner possible here.
The list of things wrong with this article is incredible.
The clueless author, Larry Seltzer, starts off by building the FUD around developments in the world of SSL. He wisely references the work of the great Moxie Marlinspike.
"A new attack is threatening to expand the potential for attackers to compromise enterprise servers and the critical data on them."
In 2009, the attacks described were new. I can't recall. What is the date??
The real meat of the sadness starts here...
"SSLStrip – A New Type of Man-in-the-Middle Attack
Marlinspike’s SSLStrip attack demonstrated the combination of several attack techniques to exploit the above weaknesses and fool users/client applications into thinking they were using a trusted site/server, when in fact they were using a fake version of that site/server. He combined a number of techniques, including “man-in-the-middle,” fake leaf node certificates and the null character attack."
Moxie's work on x509 certificates with null chars in the Subject Common Name is great! That fantastic bit or work, or rather the tool built around it, is not called SSLStrip, it is called SSLSniff. As my link shows, Moxie also built SSLStrip and it is brilliant, but has nothing to do with null chars in certs. SSLStrip cleverly MITMs the HTTP traffic from a site BEFORE you get sent to the site's HTTPS pages. It then uses several techniques to terminate SSL in the middle and render pages and links back to the victim via HTTP and stripping all HTTPS references The author then goes on to repeat the wrong name over and over, including the yearly reprints...
"SSL and web security are under attack, so what if there was a name slip", you might say. "Larry is trying to help us protect ourselves."
No Larry Seltzer is just a puppet of a vendor. I'm not sure if Larry is stupid or just makes up shit for money. Hell, I will admit here and now; Any vendor who wants to pay me well to blather about their great product should just ask. I love money!
EV SSL to the Rescue!!
"EV SSL – The Antidote for SSLStrip Attacks
We saw that with conventional certificates, especially domain-validated
certificates, there is no reliable information to back up the authentication of the
domain name. To address this critical problem, CAs and software companies joined
to form the CA/Browser Forum and promulgate a new standard called EV SSL for
Extended Validation SSL."
Yes, we are now protected. Wait, how? What? Did the LSD just kick in? I'm not going to get all technical here, but the null char problem has two parts; some CAs accidentally let these certs get issued and all major web browsers handle them badly. Wait, yes this was true in 2009, but not after all the reprints of this "white paper". Then we get to the total lie that is the "Antidote". EV SSL is mostly about stronger vetting before issuing certificates. Yes, there is are special OIDs embedded in the certs that code in the browsers check and if correct, you get some green on your screen. Wow!! Green I am sooooooo safe!!! No one cares about this green. Additionally, if you do MITM one of these sites using a certificate that otherwise is trustworthy, all the site loses is the green. There is no code in the browser that knows if the lack of green is due to evil being afoot, or the site is too cheap to pay for EV SSL.
I am safe!
Ohh, the danger!! Wait, no red X, no exclamation point?? Note the DO NOT TRUST is printed by my PoC tool (Fiddler) in the cert body specifically because the browser will throw no errors and they don't want liability.
Look, there's a fairly recent white paper from April of 2012 called, "Spoofing Server-Server Communication How You Can Prevent It"
Never mind, there it is from April of 2011.
No! WAIT! There it is from Decemnber of 2009.
This horrible piece of work came to me by email. I can't blame Symantec or VeriSign for putting it in my face, as it was sent by IDG, but pulling this work of stellar suck out once a year is sad and pathetic.
This is another case where idiots in Marketing get the bright idea to have a "journalist" "report" on something in the news that they think can sell product. I use the quotes in the most condescending manner possible here.
The list of things wrong with this article is incredible.
The clueless author, Larry Seltzer, starts off by building the FUD around developments in the world of SSL. He wisely references the work of the great Moxie Marlinspike.
"A new attack is threatening to expand the potential for attackers to compromise enterprise servers and the critical data on them."
In 2009, the attacks described were new. I can't recall. What is the date??
The real meat of the sadness starts here...
"SSLStrip – A New Type of Man-in-the-Middle Attack
Marlinspike’s SSLStrip attack demonstrated the combination of several attack techniques to exploit the above weaknesses and fool users/client applications into thinking they were using a trusted site/server, when in fact they were using a fake version of that site/server. He combined a number of techniques, including “man-in-the-middle,” fake leaf node certificates and the null character attack."
Moxie's work on x509 certificates with null chars in the Subject Common Name is great! That fantastic bit or work, or rather the tool built around it, is not called SSLStrip, it is called SSLSniff. As my link shows, Moxie also built SSLStrip and it is brilliant, but has nothing to do with null chars in certs. SSLStrip cleverly MITMs the HTTP traffic from a site BEFORE you get sent to the site's HTTPS pages. It then uses several techniques to terminate SSL in the middle and render pages and links back to the victim via HTTP and stripping all HTTPS references The author then goes on to repeat the wrong name over and over, including the yearly reprints...
"SSL and web security are under attack, so what if there was a name slip", you might say. "Larry is trying to help us protect ourselves."
No Larry Seltzer is just a puppet of a vendor. I'm not sure if Larry is stupid or just makes up shit for money. Hell, I will admit here and now; Any vendor who wants to pay me well to blather about their great product should just ask. I love money!
EV SSL to the Rescue!!
"EV SSL – The Antidote for SSLStrip Attacks
We saw that with conventional certificates, especially domain-validated
certificates, there is no reliable information to back up the authentication of the
domain name. To address this critical problem, CAs and software companies joined
to form the CA/Browser Forum and promulgate a new standard called EV SSL for
Extended Validation SSL."
Yes, we are now protected. Wait, how? What? Did the LSD just kick in? I'm not going to get all technical here, but the null char problem has two parts; some CAs accidentally let these certs get issued and all major web browsers handle them badly. Wait, yes this was true in 2009, but not after all the reprints of this "white paper". Then we get to the total lie that is the "Antidote". EV SSL is mostly about stronger vetting before issuing certificates. Yes, there is are special OIDs embedded in the certs that code in the browsers check and if correct, you get some green on your screen. Wow!! Green I am sooooooo safe!!! No one cares about this green. Additionally, if you do MITM one of these sites using a certificate that otherwise is trustworthy, all the site loses is the green. There is no code in the browser that knows if the lack of green is due to evil being afoot, or the site is too cheap to pay for EV SSL.
I am safe!
Ohh, the danger!! Wait, no red X, no exclamation point?? Note the DO NOT TRUST is printed by my PoC tool (Fiddler) in the cert body specifically because the browser will throw no errors and they don't want liability.
As Larry does mention other developments in security, lets look at SSLStrip seeing how he spells the word repeatedly and never covers it. SSLStrip keeps the victim from ever getting SSL to the target site, so no SSL cert can help us here. The only thing Moxie hasn't solved is the lack of green, but again, no one notices or cares. I am one of the most paranoid web surfers I know, but how would I know if a site should have green or not. It's not that common...
The real tragedy here is that VeriSign commissioned the "white paper" and no one any intelligence reviewed or fact checked it, or wrote it. ;-) Then Symantec re-branded the thing, edited it a tad bit, but still never checked any facts.
All in all, this is what I have come to expect from Symantec.
Subscribe to:
Posts (Atom)