Tag: SSL

Events
by Jayson Salazar

SSL Tidbits at the BASTA.NET

A while a go Dominik and I gave an introductory presentation about SSL at the BASTA.NET conference, a developer-oriented event held in Darmstadt twice a year. At that time there were quite some enthusiastic participants but recently we’ve also gotten some inquiries asking for the relevant materials. Although there’s no recording of the session, we’ve decided to put the slides here for those interested who didn’t make it to the talk.

“Who should have a look at the slides?” you ask, well, if you’ve been wanting to get a sense for what the idea behind SSL is, where it is used, how it is usually leveraged and what problems could arise when poorly employed, you will certainly find the slide-deck interesting. Although the session was meant to slowly get participants up to speed in matters SSL, it’s still likely that more informed folks will still find it interesting, even if just as a refresher about key and certificate formats, PKI 101, SSL stripping, secure cookies, and other topics.

Without further, here’s slide deck.

For the hungry, here are some other interesting resources we suggested to attendees willing to go a bit deeper on the topic after the talk.

– OWASP – SSL für Alle
– OWASP – Transport Layer Protection Cheat Sheet
– Mozilla – Server Side TLS

For those attending to the BASTA.NET next autumm, we’re looking forward to meeting you. But for the time being, that’s going to be pretty much it.

Thanks for reading and let us know what you think.

Continue reading
Breaking
by Enno Rey

New SSL/TLS MiTM Attacks

A number of customers has approached us with questions like “Those new MiTM attacks against SSL/TLS, what’s their impact as for the security of our SSL VPNs with client certificates”?
In the following we give our estimation, based on the information publicly available as of today.

On 11/04/09 two security researchers (Marsh Ray and Steve Dispensa) published a paper describing some previously (presumably/hopefully) unknown MiTM attacks against SSL/TLS. CVE-2009-3555 was assigned to the underlying vulnerabilities within SSL/TLS.
The attacks described might potentially allow an attacker to hijack an authenticated user’s (SSL/TLS) session. In an IETF draft published 11/09/09 and describing a potential protocol extension intended to mitigate the attacks the following is stated:
“SSL and TLS renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client.  The server treats the client’s initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data.”

Obviously this _could_ have dramatic security impact on most SSL VPN deployments. Still, within the research community the impact on SSL VPNs seems unclear at the very moment.
On monday, Cisco issued a somewhat nebulous security advisory classifying the Cisco AnyConnect VPN Client as _not_ vulnerable (but quite some other products). OpenVPN disposes, for some time already, of a particular directive (tls-auth) which is regarded as an effective way to mitigate the vulnerabilities. Other vendors (e.g. Juniper) have not yet issued any statements or advisories at all (see also here for an overview of different vendors’ patch status).
This might be a good sign (“no problems there”), it might just be they’re still researching the pieces.

After discussing the problems with other researches we expect more concrete attack scenarios to emerge in the near future and we expect some of those future attacks to work against _some_ SSL VPN products as well. In case you have some SSL VPN technology in use pls contact your vendor _immediately_ asking for an official statement on this stuff.
Sorry for not having better advise for you right now. We do not want to spread FUD. On the other hand it might be a cautious approach to “expect the worst” in this case. There’s vast consensus amongst researchers that this _is a big thing_ that most people did not expect in this protocol. A first public break-in based on the vulnerabilities has already been reported.

Continue reading