It’s hard for me to get too worked up about this vulnerability:
Many popular applications, HTTP(S) and WebSocket transport libraries, and SOAP and REST Web-services middleware use SSL/TLS libraries incorrectly, breaking or disabling certificate validation. Their SSL and TLS connections are not authenticated, thus they — and any software using them — are completely insecure against a man-in-the-middle attacker.
Great research, and — yes — the vulnerability should be fixed, but it doesn’t feel like a crisis issue.
Posted on November 7, 2012 at 1:39 PM •
EFF reports on the security of SSL:
The most interesting entry in that table is the “CA compromise” one, because those are incidents that could affect any or every secure web or email server on the Internet. In at least 248 cases, a CA chose to indicate that it had been compromised as a reason for revoking a cert. Such statements have been issued by 15 distinct CA organizations.
Posted on October 27, 2011 at 6:45 AM •
Iran blocks Tor, and Tor releases a workaround on the same day.
How did the filter work technically? Tor tries to make its traffic look like a web browser talking to an https web server, but if you look carefully enough you can tell some differences. In this case, the characteristic of Tor’s SSL handshake they looked at was the expiry time for our SSL session certificates: we rotate the session certificates every two hours, whereas normal SSL certificates you get from a certificate authority typically last a year or more. The fix was to simply write a larger expiration time on the certificates, so our certs have more plausible expiry times.
Posted on September 26, 2011 at 6:41 AM •
It’s the Browser Exploit Against SSL/TLS Tool, or BEAST:
Using the known text blocks, BEAST can then use information collected to decrypt the target’s AES-encrypted requests, including encrypted cookies, and then hijack the no-longer secure connection. That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long.
The attack, according to Duong, is capable of intercepting sessions with PayPal and other services that still use TLS 1.0which would be most secure sites, since follow-on versions of TLS aren’t yet supported in most browsers or Web server implementations.
While Rizzo and Duong believe BEAST is the first attack against SSL 3.0 that decrypts HTTPS requests, the vulnerability that BEAST exploits is well-known; BT chief security technology officer Bruce Schneier and UC Berkeley’s David Wagner pointed out in a 1999 analysis of SSL 3.0 that “SSL will provide a lot of known plain-text to the eavesdropper, but there seems to be no better alternative.” And TLS’s vulnerability to man-in-the middle attacks was made public in 2009. The IETF’s TLS Working Group published a fix for the problem, but the fix is unsupported by SSL.
EDITED TO ADD: Good analysis.
Posted on September 23, 2011 at 1:37 PM •
There’s been a forged Google certificate out in the wild for the past month and a half. Whoever has it — evidence points to the Iranian government — can, if they’re in the right place, launch man-in-the-middle attacks against Gmail users and read their mail. This isn’t Google’s mistake; the certificate was issued by a Dutch CA that has nothing to do with Google.
This attack illustrates one of the many security problems with SSL: there are too many single points of trust.
EDITED TO ADD (9/1): It seems that 200 forged certificates were generated, not just for Google.
EDITED TO ADD (9/14): More news.
Posted on September 1, 2011 at 5:46 AM •
This isn’t good:
The hacker, whose March 15 attack was traced to an IP address in Iran, compromised a partner account at the respected certificate authority Comodo Group, which he used to request eight SSL certificates for six domains: mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org and login.live.com.
The certificates would have allowed the attacker to craft fake pages that would have been accepted by browsers as the legitimate websites. The certificates would have been most useful as part of an attack that redirected traffic intended for Skype, Google and Yahoo to a machine under the attacker’s control. Such an attack can range from small-scale Wi-Fi spoofing at a coffee shop all the way to global hijacking of internet routes.
At a minimum, the attacker would then be able to steal login credentials from anyone who entered a username and password into the fake page, or perform a “man in the middle” attack to eavesdrop on the user’s session.
More news articles. Comodo announcement.
Fake certs for Google, Yahoo, and Skype? Wow.
This isn’t the first time Comodo has screwed up with certificates. The safest thing for us users to do would be to remove the Comodo root certificate from our browsers so that none of their certificates work, but we don’t have the capability to do that. The browser companies — Microsoft, Mozilla, Opera, etc. — could do that, but my guess is they won’t. The economic incentives don’t work properly. Comodo is likely to sue any browser company that takes this sort of action, and Comodo’s customers might as well. So it’s smarter for the browser companies to just ignore the issue and pass the problem to us users.
Posted on March 31, 2011 at 7:00 AM •
Sidebar photo of Bruce Schneier by Joe MacInnis.