pgpdump is a PGP packet visualizer.

pgpdump is a PGP packet visualizer which displays the packet format of OpenPGP (RFC 4880) and PGP version 2 (RFC 1991). Availability: – The first…

Link: http://seclist.us/pgpdump-is-a-pgp-packet-visualizer.html

EV-SSL, SSL, And Who’s Not Using It

It seems I’ve been picking on EV-SSL lately. It’s not intentional; I just have encountered a lot of questionable marketing fluff lately and wanted to talk about it. Today is no different. Tim Callan’s recent blog post got me thinking. Basically he referenced some SSL attacks that were disclosed at BlackHat, and suggested EV-SSL certificates as the cure to SSL MitM attacks and phishing in general. On the one hand, I believe his conclusion is conveniently aligned with his employer’s sales agenda. On the other hand, I acknowledge that EV-SSL could raise the bar…if it’s adopted and deployed in widespread fashion. And therein is the crux.
I’ve previously talked about the EV-SSL adoption rate (or lack thereof) in this blog. NetCraft has reported its findings of one million valid SSL-capable sites are in use (note: sites with invalid, self-signed, or expired SSL certs are not included in that count). And while I don’t have access to their commercial SSL Survey report for January 2009, we infer from some third party mentions that the report states around 10,000 EV-SSL sites were found. That’s 3,000 more than Verisign mentioned last month, but perhaps Verisign was only reporting what they alone issued. Given their marketshare (~75%, albeit that number is a year old) against total EV-SSL cert vendors, that seems to make sense.
Only 10,000 EV-SSL sites within two years seems very low to me, especially for something which is essentially an enhanced derivative of an already understood and accepted technology. People already know what SSL is and what function SSL certs perform, so that definitely is not the hold up. There just doesn’t seem to be much of an adoption momentum, and maybe that’s because the additional value these premium EV-SSL certs provide is questionable in the eyes of site owners.
But maybe I’m looking at this wrong. Only 10,000 EV-SSL sites seems a bit low, but what if they were 10,000 sites that matter? I suppose that would paint a different picture. If 10,000 big sites that account for a notable portion of the web’s traffic used EV-SSL, I suppose that actually might not be so bad. So I entertained that theory. I manually surfed to each of the upper 50 of Alexa’s Global Top 500 Sites list, and recorded who was using EV-SSL vs. normal SSL vs. no SSL. The idea is that these sites represent the most visited sites in all of the world (according to Alexa), and as such, assumingly have a vested interest in assuring their voluminous user population that the users’ accounts and transactions are secure. If most of these sites were using EV-SSL, then that would actually provide notable EV-SSL permeation into overall web traffic.
The process I used was simple: visit each of the Alexa-listed sites (the top 50), surf around to find a ‘signin’ or ‘signup’ form or other equally-sensitive use of HTTPS, and then watch if the URL address bar in my Internet Explorer 7 browser turned green when SSL was utilized. A green bar meant EV-SSL; no green bar but still having a valid lock icon is standard SSL. I found that only two sites (ebay.com and login.live.com) were using EV-SSL. That’s it. Just two. All of the other sites were using standard SSL, with the exception of ten sites that don’t use SSL at all with their login forms (youtube.com, hi5.com, mail.ru, photobucket.com, vkontakte.ru, imageshack.us, friendster.com, skyrock.com, odnoklassniki.ru, and dailymotion.com) and two more that don’t really receive sensitive info from the user and thus don’t necessitate SSL (bbc.co.uk and cnn.com).
We might label that a bleak picture. Ten of the fifty top sites (20%) don’t even use SSL for their logins. Only two use EV-SSL. I was a bit surprised to see the online retail giant, Amazon.com, didn’t use EV-SSL. If EV-SSL was a sure-thing to lead to better customer confidence and more online retail conversions, I would have figured they would have been all over it. They would not be one to overlook a technological advantage if the ROI helped their bottom line…that is, after all, how they got started. And given that they store credit card data for quick purchasing convenience, there is a certain financial value to compromising someone’s Amazon account; I’m surprised it hasn’t been the target of more phishing attacks to date.
Also surprising was Yahoo (login.yahoo.com), AOL (my.screenname.aol.com), and Google (www.google.com) all use standard SSL for their common backend authentication sites. These vendors offer multiple different web services, but tie it all back to a single authentication mechanism, much like a Single Sign-On (SSO) platform. And aren’t some of these vendors OpenID providers? That means a successful phish of a single account could be leveraged across many sites/services, even outside the realm of just these vendors. On Microsoft’s live.com site, I found that the login form (from login.live.com, which was presented over HTTP by default but did include a link to switch to HTTPS) did go to an EV-SSL site once submitted, but the signup page (signup.live.com) was handled with a standard SSL cert. Maybe they just want to discourage new signups while assuring existing accounts it’s safe to login.
But here’s another thought: maybe these sites have invested in standard SSL certificates before EV-SSL was popular, and just are waiting for their current certs to expire before renewing with EV-SSL variants. That seems plausible, but the results are a bit mixed. Google renewed their current standard SSL cert in May 2008 and signup.live.com was renewed in November 2008. That was fairly recent, and definitely after EV-SSL was well established. Opposite that, AOL’s my.screenname.aol.com certificate was issued in March 2007 and Yahoo’s is from January 2006; it’s arguable they were issued before EV-SSL really caught on. So it’s hard to say, but the thought might hold true for some cases. Certainly not others.
But again, maybe I’m still looking at it all wrong. EV-SSL might only make the most sense to certain verticals, like online banking sites. The Alexa list doesn’t really have any bank sites in their top 50. So I did a spot-check of some big bank site URLs pulled from the top of my head. Of all the ones I tried, only BankOfAmerica’s login site (which is separate from their normal site) used EV-SSL:
 
 
 
www.bankofamerica.com: standard SSL (renewed December 2008)
sitekey.bankofamerica.com: EV-SSL
www.wellsfargo.com: standard SSL (renewed June 2008)
online.wellsfargo.com: standard SSL (renewed July 2008)
www.chase.com: standard SSL (renewed August 2008)
chaseonline.chase.com: standard SSL (renewed April 2008)
online.citibank.com: standard SSL (renewed December 2007)
www.us.hsbc.com: standard SSL (renewed July 2008)
myonlineaccounts2.abbeynational.co.uk: standard SSL (renewed February 2009**)
That last one is very interesting. Abbey National Bank has been a notable target of phishing attempts going back a year. And yet, when they renewed their SSL certificate last week (February 12, 2009), they went with a standard certificate instead of EV-SSL. Whether they didn’t know or didn’t care that EV-SSL could help assure users against phishing, I don’t know. But if a bank that’s been phished for over a year doesn’t decide to buy into EV-SSL when it has the convenient opportunity…who will? Marketing fluff aside, that is probably the absolute best-case realized application for EV-SSL ever. User accounts have access to monetary instruments. The site has been an active target of phishing attempts for over a year. They needed new SSL certs anyway. Any one of those reasons by itself is (supposed) ground for EV-SSL, and they had all three reasons. Oh well, maybe they’re reconsider EV-SSL in 2010 when their new cert expires.
Until then,
– Jeff
**Postscript: it seems Abbey National Bank’s site uses a cluster of SSL web servers that have different SSL certs installed. In some cases, I connect to a server that gives me an SSL cert that was issued on Feb 12 2009. On other occasions, I get connected to a server that gives me an SSL cert that expires on Feb 24 2009 (i.e. next week). So apparently they have currently upgraded the SSL certs on some of their servers, but not all. I just wanted to mention this in case you were poking around yourself and noticed the discrepancy. Here is a screenshot of the newer SSL cert, to prove I’m not making stuff up:
 
 
 

Link: https://www.zscaler.com/blogs/research/ev-ssl-ssl-and-whos-not-using-it

The ‘SSL Encryption Without Authentication’ Debate

Every so often I encounter a debate where an individual is making a case for the value of supporting/accepting self-signed SSL certificates in browsers. Basically their argument is “I do not care about authentication of SSL, I just want the encryption part…so why should I have to pay VeriSign or another commercial CA all that money for an SSL certificate that verifies my identity?” This question seems to be newly fueled by the fact that Firefox 3 now requires the user to go through a laborious 4-step process to allow the browser to connect to an SSL site utilizing a self-signed certificate.
The problem is: anyone who asks the above question is ignoring how SSL works and how SSL employs encryption in the first place. If you are trying to keep an evil person from learning your secrets, but you do not authenticate who you are talking to, you are basically overlooking that you may well be telling your secrets to the evil person directly! If you don’t authenticate the identity of someone, they are essentially an unidentified stranger to you. And the idea of wanting to keep your secrets from strangers (i.e. encryption) but also be willing to give your secrets to strangers (i.e. no authentication) is contradictory. If you have no idea of who you are talking to, then what value is the encryption really providing? How do you tell a complete stranger a secret in private and still expect the secret to remain safe from strangers?
Let’s look at how SSL tackles authentication via the use of certificates. A signed (i.e. authenticated) certificate is essentially a digital record that says “My name is Bob, and this big trusted company over here agrees with that statement.” The idea is that browsers trust a set of big trusted companies (Certificate Authorities such as VeriSign, Thawte, etc.), and that creates a trust chain: we trust the browser, the browser trusts the CA, the CA says this is Bob, so we trust it is Bob. On the other hand, a self-signed (i.e. non-authenticated) certificate is a digital record that says “My name is Bob, and you will just have to trust me that what I am saying is true.” It’s almost like the honor-system approach of everyone stating who they are; but how do we know if they are lying? Essentially, you don’t…because self-signed certificates can be created by anyone to say anything (that is the whole purpose of self-signed certificates). An evil attacker can trivially generate certificates that say “My name is Paypal, and you will just have to trust me,” “My name is eBay, and you will just have to trust me,” “My name is Bank of America, and you will just have to trust me,” etc. The only thing that prevents the attacker from deceiving you with these malicious self-signed certificates is your browser’s better judgment of not trusting these arbitrarily fabricated declarations of identity having no proof. Remember: security is about keeping you safe despite lies and deception; we need to ensure that a simple lie by an attacker won’t compromise the entire process. In this case, self-signed certificates offer a way for attackers to lie about their identity with impunity.
So let’s go back to the original premise of the question and look a bit more technically at what’s going on. The argument is the desire to have encryption without authentication. That means the sensitivity and secrecy of the data is still an issue/desire, otherwise, why bother with encryption? The primary threat vector mitigated by end-to-end encryption on a network is passive eavesdropping (a.k.a. network sniffing). But keep in mind that, in SSL, the encryption keys are dynamically negotiated by the two endpoints at the start of the connection (after authentication has concluded). Thus encryption by itself offers no security value if the passive eavesdropping attacker decides to switch to an active man-in-the-middle or interception attack (which is technically viable if they were already in a position to eavesdrop your network traffic to begin with); this just means you are now negotiating an encryption key with the attacker and directly sending them your data. SSL normally mitigates these attacks by the use of authentication, to ensure the endpoint you negotiate your encryption key with is indeed who they say they are. However if we allow self-signed certificates to be used and therefore overlook the authentication aspect, there is zero guarantee that the person you just negotiated an encryption tunnel with isn’t the person you were trying to secure your information from (via encryption) in the first place. True, it does require the attacker to switch from a passive attack to an active attack, but that is of little consequence if the attacker truly wants to compromise the data. And attackers are already playing very active roles in attacks today (setting up an entire phishing site and sending out phishing emails isn’t exactly a passive affair…).
I have a hunch the real motive behind petitioning for self-signed certificate support is purely economic. Web site operators want to appear to conform to user expectations of security and privacy via the use of SSL (the whole “make sure the little lock icon appears in your browser before you send sensitive info” mantra), but without having to shell out cash for a real SSL certificate (if they just paid the money for a proper CA-signed certificate, this whole debate is moot). It’s the façade of security without actually delivering on the promise. But those that are using self-signed SSL certificates for production uses, even prior to the newer crop of browsers handling them less favorably, are already doing a slight injustice to security as whole—because they are forcing a user to essentially make a “Yes I know this is insecure, please proceed anyways” decision. Accepting self-signed certificates in older browsers is usually just a semi-scary dialogue followed by a one-click override from the user….and apparently the protagonists of this debate believe this (was) acceptable for users to do. But isn’t that just exacerbating the phenomenon of users continually making bad security choices, by explicitly encouraging them to do so? We should not be encouraging users to bypass or override security protection mechanisms put there for their own good; what starts as an encouraged exception may eventually become an assumed norm (I’d like to make a Pavlov reference here, but I don’t want it seen as belittling the behavior or intelligence of users).
All of that said, I suppose there are some certain approaches that may offer a balanced compromise. If we look at SSH, we encounter the same basic problem: when the client first connects to the server, it doesn’t know if the server is actually the right server or not. So usually the client prompts the user with a small fingerprint of the server’s identity in order to verify that identity out-of-band. If the user instructs the client to proceed, the client caches the server’s identity fingerprint. From that point on, as long as the server’s identity fingerprint matches what is cached, life is good. If that identity fingerprint ever changes, then lots of security bells and whistles go off because something is afoot, such as a man-in-the-middle attack (or the server admin re-generated their identity information, which is not something done arbitrarily). Basically it reduces the “no-authentication” scenario down to only the very first, initial connection that the client makes to the server. An attacker would have one chance—and one chance only—to intercept that very first connection and supply impersonated credentials. But also keep in mind, if the attacker stops the interception ruse and allows the connections to proceed to the proper server, the client will immediately alert the user to something fishy because the server identity (as seen by the client) has changed. So an attacker can remain undetected if and only if they intercept that very first connection, and only for as long as they actively and continually intercept all future connections. That reduces the chance of successful attack to a very small window, and requires moderate effort on part of the attacker to remain undetected. Perhaps this approach could be adapted to browsers, where a self-signed certificate for a given site can be manually verified once (the first time), and then cached so that as long as the certificate doesn’t change, it can be assumed to be the same site. It is entirely a change to the client browser and how SSL certificates are validated; no SSL protocol or server-side changes are necessary.
But unless browsers were to enact such a change, the use of self-signed certificates in this day in age is a risky proposition. They are fine for testing purposes, but they should never be used in production with real users. An alternate approach to using self-signed certificates is to create your own CA (you can use the free OpenSSL suite to do so) and use your CA to sign your server certificates; then encourage your users to install your CA certificate. This at least maintains the integrity and security value of the SSL protocol, and would allow the users’ browsers to function without any security warnings requiring user interaction. However, you must then guard your CA private keys thoroughly, as you have now because a trusted entity in the browser’s eyes; if your CA keys are stolen, it would allow attackers to generate arbitrary certificates that are signed by your CA. In other words, the attacker could create the equivalent of arbitrary self-signed certificates but would actually use you as the trusted signing authority, and since the users’ browsers now trust your CA, the browsers would inherently trust all of the attacker’s certificates.
Regardless of what you do, one thing is for certain: you do not want to be the weakest link in the security chain. SSL literally has a trust chain established by the use of authentication certificates, and trying to bypass authentication (and the associated trust chain) compromises all security (including encryption) offered by SSL. No one likes being identified as the weakest link, so save your company the PR trouble and just buy that SSL certificate from a proper CA. It’s what is best for everyone involved, and your wallet will recover.
– Jeff

Link: https://www.zscaler.com/blogs/research/ssl-encryption-without-authentication-debate