After I updated to version 1.7. I could not connect to our internal repository anymore. The connection failed with the following error: SSL error: sslv3 alert certificate unkown.

SSL error: sslv3 alert certificate unknown

Our internal respoitory is secured with a certificated issued by our internal CA infrastructure.

Root CA

|
v

Intermediate Certificate

|
v

Repository certificate

Surfing to the svn repository does not produce an error, so the certificate chain is fine. At first I figured that Tortoise was using its own certificate store, but it turns out that Tortoise does use the Windows Root CA store, so there is no need to add the Root CA.

After some more investigation we found out that Tortoise does use the Windows Root CA store to validate the certificate chain, but does not use the Intermediate CA store to complete the certificate chain, like windows does. Since all our client machines have the intermediate certificate in the Intermediate CA store we never noticed that the certificates offered by apache were not chained. After chaining the repository certificate with the intermediate certificate Tortoise was able to talk to the repository again.

Breaking the ice a cc nc nd by image from MarcelGermain's Flickr stream

By Ivan Ristić

Slides on the HitB Materials page.

Ivan researches SSL for Qualys. SSL was designed as a protocol add-on by Netscape to secure http, but can be used to secure other protocols as well.

The main challenges today are:

1. Fragility of the trust ecosystem
2. Incorrect or weak configuration
3. Slow adoption of modern statndar
4. Lack of support for virtual SSL hosting
5. Mismatch between HTTP and SSL

There are three main attacks against SSL:

• Passive MitM

• Session Hijacking

• Session bypass (ssl strip)
• Renegotiation attack
• Rogue certificates
• User attackers (who reads warnings)

Ivan’s has a lot of data based on the a surveys conducted by his employer Qualys SSL Labs, EFF’s SSL Observatory. In total 1.2million sites with valid certificates where investigated.

Ivan showed a slide that indicates that of the sites visited only 0.6% of the sites had a fully correct SSL configuration, nearly 50% of the sites did not offer SSL at all.

In Qualys’ most In the most recent SSL Survey only 32% of the sites offering SSL where configured correctly.

So now for the bad stuff:

• 48% of the sites offering SSL still offer SSLv2 which is know to be cryptographically insecure, it is a good thing that most browsers reject it
• Most sites do not offer any support for TLSv1.1 and TLSv1.2
• 62% of the sites still use weaks ciphers
• The TLS renegotiation vulnerability discovered in 2009 still effects nearly 35% the sites

But it is not just about how SSL is configures, but also about how it is used:

• Nearly 80% of the sites offering SSL do not redirect their users to the secure sites by default.
• HTTP Strict Transport Security is only used by 80 out of the the nearly 250,000 sites tested by Qualys.
• The adoption of EV certificates is also low
• Of the tested sites on 9 used all three above techniques.
• A lot of sites mark their cookies as HttpOnly or Secure, but even less that use both techniques
• 22% of the tested sites use some form of mixed content, if you exclude the sites that only use it for images this number only drops slightly to nearly 19%
• 68% of the login forms where not served over HTTPS and 54% submitted data to an http site

So what can we concluse:

• Systematic issues are hotly debated
• However SSL is often broken  by bad deployment and implementation issues
• It is possible to achieve reasonable security, but most sites choose not to do it
• Among the popular sites only a handful have decent SSL deployments

SSL is a success because it bought a relative security to the general public.

You can download the slides below:

• TLS renegotiation authentication GAP v1.1 pdf
• TLS renegotiation authentication GAP v1.1 pptx

Special thanks to Marsh Ray for his suggestions and corrections.

This new attack adds to the issues published by Moxie Marlinspike, Dan Kaminski and Mike Zusman I blogged about earlier.

So what does this new attack do?

The attack described by Marsh Ray et al. exploits a feature of the TLS protocol called renegotiation. Renegotiation allows the TLS client or server to initiate a renegotiation of the encryption of the connection in order to refresh keys, increase authentication, increase the strength of the cipher suite or any other reason. This renegotiation can be performed by the server or the client by sending a server or client hello message.

The man in the middle attack works by intercepting and forwarding the first client hello message sent by the client (C) to the server (S) and then negotiating the cipher between the Man in the Middle (M) and the server only. At this point there is an encrypted session between M and S and M can insert his own data into the connection and even read the reply for the period that the underlying protocol (e.g. HTTP for HTTPS) allows for a reply to arrive. M then replays the original client hello message received from C which will start a renegotiation of the cipher between C and S. Depending on the timing of the replay of the client hello message C will either append its request to M’s request, receive the answer to M’s request or will not be aware of M’s request and S’ reply to M’s request.

TLS handshake with MitM renegotiation attack

Using techniques similar to request smuggling M can even insert his own request into a session that requires client certificate authentication. In fact the original whitepaper’s first example deals with TLS renegotiation in case of client certificate authentication. Like Cross Site Request Forgery this attack allows an attacker to send requests to resource within the, possibly authenticated, context of the client.

Because this attack requires the attacker to manipulate the traffic stream between client and server and is thus classified as a man in the middle (MitM) attack, it does not allow the attacker to decrypt any traffic sent between client and server.

What are the consequences of this attack?

While this attack does not completely break TLS, it does break on of its fundamental functions, in that it does not fully guarantee the integrity of the first request from the client to the server. This means e.g. that the attacker could insert a transaction into an online banking application without the user being aware.
This attack does NOT affect the integrity of the reply from the server to the client (other than maybe not sending the reply to the client), so it does not allow the attacker to rewrite the reply from the server to the client. This means that if, e.g. an online bank publishes an overview of the transactions before and after the transaction is authorised, the user can spot the inserted transaction.

The attack also does not affect the confidentiality of either the original request or the reply from the server, however as with cross site request forgery, it may allow an attacker to use the clients credentials (e.g. a client certificate, cookie, or password) without knowing them.

While the attack only works for the first request sent over a TLS session (subsequent renegotiation requests are sent in the encryption context and can thus not be inserted) M could force the session to reset after x seconds of inactivity by sending a reset packet to both C and S, thus forcing a new TCP and TLS session to be re-established and thus gaining a new window of opportunity.

What can be done against this attack?

Currently there are no fixes available. In their whitepaper Marsh Ray et al describe several possible solutions, which unfortunately all more or less break backwards compatibility.

In response to this attack OpenSSL today released OpenSSL 0.9.8l which does not fix the vulnerability, but disables renegotiation completely. This change to OpenSSL may break certain applications so it should be carefully tested before it is implemented.
From an HTTPS perspective the problem has similarities with cross site request forgery and can be defended against in a similar manner. If a program requires a unique session ID with sufficient entropy as part of the URL this session ID cannot be read or reused by the attacker.
The problem currently has the full attention of Internet Engineering Task Force (IETF) TLS workgroup so hopefully they will come up with a fix soon. In the mean time you could disable renegotiation for OpenSSL based products if this does not break the application stack.

Conclusion

While the attack does not break the confidentiality of the communication between client and server it does allow an attacker to insert text into the first request of the client, thus breaking its integrity. This issue is a fundamental protocol level issue that cannot be fixed without breaking backward compatibility. If the application using TLS (e.g. HTTPS) does not need renegotiation, turning renegotiation off may be a possibility, however there are numerous situations where renegotiation is needed (e.g. certain scenarios where client certificate authentication is used for https).
I do not agree with Moxie Marlinspike who was quoted to say “It doesn’t affect your webmail, online banking or online shopping experience.” However the attack is hard to use and the attacker will need to have detailed knowledge of the application he is attacking. This attack will first appear in highly targeted scenarios. Since the attack is a man in the middle attack the attack will have to have control over all the traffic between client and server and vice versa in order to fully exploit the attack.

With this attack TLS does not fully protect the integrity of the communication between client and server.

Moxie developed a tool and technique called SSLSNIFF which is able to do undetectable Man in the Middle attacks on SSL connections exploiting the possibilities null terminated certificates offer. He defined three possible counter measures against his attack. Certificate validation, software updates and extended validation certificates. Unfortunately he was able to defeat two of these three measures.
Certificate validation these days is handled mostly by the OCSP, the Online Certificate Status Protocol. Marlinspike found a flaw in the protocol. On of the statuses the OCSP can send back is “Try later…”, represented by the number 3. Such a reply does not need to be signed by the CA an causes the browser to fail open, or as Moxie put it: “OCSP is defeated by the number 3”.
Software updates can be another issue. At the time of the presentation, these bugs where only fixed in Firefox 3.5, so how do you prevent people from updating to this version? Most browsers these days have a so called auto update function, this function searches online for a more recent version of the browser, addons or plugins. In order to ensure that no malicious content is installed, the browsers rely on SSL, the same SSL that was broken by Marlinspike’s SSLSNIFF.

But there is more trouble in paradise. Marlinspike also demonstrated a technique het called ssl stripping. Ssl stripping does not attack SSL itself, instead it actually attacks, what Moxie described as the bridge between http and https. “Https is today’s world is not often encountered directly. Users don’t often type https:// in the address bar themselves. In stead they get redirected to an https site or click on a link to it”. By performing an man in the middle attack on the http connection and carefully rewriting all https requests to http requests, Marlinspike was able to create near exact copies of the login pages for services such as gmail and paypal. The user would only know something is wrong, if they notice that the https prefix is not there or that the padlock symbol is missing.

Dan Kaminski was also able to exploit the common name field to get certificates he should not be getting. Different implementations of certificate validation routines have flaws when it comes to handling certificates with multiple common names in them. By requesting a certificate with three common names: CN=www.ioactive.com, CN=www.bankofameric.com and CN=* Kaminski was able to get a certificate that would perceived as follows; the CA would sees the certificate as an www.ioactive.com certificate, which Kaminski is allowed to request. Internet Explorer will interpret the certificate as a www.bankofamerica.com certificate and Firefox will allow the certificate to be used for any url.

Besides the common name abuse, Kaminski also showed us that there is still an MD2RSA signed root certificate present in all browsers. While practical exploitation is not possible at the moment, it is very likely that this possible in the near future. Most browser vendors are working to fix the issue right now, but Kaminski kindly requested his public to “please, do not hack MD2 in the next six months.”

The last talk I attended was Mike Zusman’s “Criminal Charges not Pursued, Hacking PKI”. Mike used another technique to get “interesting” certificates. By exploiting a flaw in the web application of a CA, he was able to request certificates for pretty much any domain he wanted.

One of the solutions seems to be popping up is Extended Validation, which in a sense takes us back a couple of years. A few years back, the only way to buy a certificate was to provide legal evidence that you had control over a domain via an out of band mechanism to a human, but then these persons at the CA’s where replaced by an online application with an automated validation process and the fun started.

Extended Validation changes this by enforcing standards for validation and requiring validation by a human before the certificate gets issued. Extended Validation (EV) CA’s are hard coded in the browser to prevent the addition of malicious CA’s. But EV certificates get trusted just as much as classic certificates.

Mike Zusman was able to perform a man in the middle attack PayPal, which uses an EV certificate to protect its site. What his program does is only redirect a small portion of the traffic, the actual login, to his own malicious website which has a non-EV www.paypal.com certificate obtained via on of the methods described earlier. The only side effect visible to the user is a brief flickering of the green address bar. But will a user notice or care?

Obviously dual factor authentication, like PayPal’s security key, will reduce the risk, but what can we really do?

I was able to share a beer with Mike after he presentation and it looks like there are fundamental underlying problems with the current certificate structure. Here we have architecture of trust, yet its foundations are built on the known insecure DNS database. Browser vendors claim they have this set of rules that should be obeyed in order for a CA to be included in the browser, yet practice shows that certain CAs that have not followed these rules are still in the browser, while on commercial CAs, like CAcert are having a hard time getting included in browsers for what seems to be political reasons.
It is time to ask ourselves fundamental questions like: Is it a good thing that a browser vendor determines who’s assertion of identity to trust. There is a trend that browsers make it harder to accept invalid certificates. Mike said: “It currently takes more clicks to accept an invalid certificate, then to import a new CA”. Is this a good thing?

Both Zusman and Kaminski agree that is would be a good thing if we had a trustworthy DNS structure that we could just to, e.g. store the fingerprints of certificates that are valid for our domain. Unfortunately DNSSEC is currently in a status quo. The current implementation still got issues, but until the root servers are going to be signed nobody will be motivated to fix these issues.

Moxie wrote the tool SSLSNIF is that is able to do a man in the middle attack on  an SSL connection based on this vulnerability to proof to Microsoft that it could be exploited, contrary to what Microsoft said.

Even tough Microsoft and others fixed the vulnerability, the tool is still useful, mainly because people don’t pay attention to certificate warning. Also when the guys that made the fake CA certificate by means of the the MD5 collision use SSLSNIFF to actually exploit is.

But there are more ways to attack SSL then doing a man-in-the-middle attack; SSL Stripping

SSLSTRIP actually attacks SSL before we get there by doing a MitM attack on http. Most https links are not typed, but clicked on or redirected to. SSLStrip watches the http traffic go by and modifies links to https sites to links to http, but it still does the https connection in the backend.

The server thinks is everything is normal because it is receiving valid https requests, the client does not display any warnings, but they are missing lock, but because the user is trained to pay attention to negative feedback and not look for positive feedback, this is not a big issue.

Where do we need to go next?

SSL needs to provide Secrecy, Authenticity and Integrity in order to be effective.

One of the issues is that today there are no people involved anymore with SSL certificates. Just domain validation which is based on a Whois lookup of root of the subject. This provides an email address or phone number to send a token to.

The standard for the DN has totally broken down. Most implementations just look at the CN= part. The CN is stored as a ASN1 string in memory, so they are basically Pascal strings, which means that the actual string is prepended by a byte representing the length. The null character is a valid part of CN string. However if you use the C routine Strcmp() it will actually regard www.paypall.com\0evil.org the same as www.paypall.com.

This bug exists in most web browsers, mail clients, chat clients and SSL vpn solutions like Citrix.

SSLSNIF 6.0 supports this.

Drawback of this attack: It needs to be targeted

Most of these products use NSSto do their certificate validation. If you look at the size and structure of the CN comparison code, there must be a bug in there somewhere.

There is: a certificate for *\0thoughtcrime.org will actually work. This is better then a CA certificate. *~thoughtcrime.org will work as well for some strange issue. As will grouping. CN=(www.paypal.com|www.google.com|www.bankofameric.com)\0.thoughtcrime.org actually works as well.

Also there is a flaw in the code thas actually remotely exploitable: (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\0OVERWRITE).foo.com. And the good thing is, the certificate does not even need to be signed.

Wildcard support is in SSLSNIF as well.

It does fingerprint the clients as well to see if they are SSN clients.

Two measures work against these attacks: Revocations and software updates.

These days most revocations are checked via OCSP. The OSCP response “try later”, the number 3, does not need to be signed. Most SSL implementations will assume a cert is valid if a “try later” rsponse is sent.

This is now also in SSLSniff.

Updates

Most software has an auto update function, e.g. take Firefox or Thunderbird. Unfortunately, these update mechanisms themselves could be a problem. Actually, Firefox/Thunderbird update files are not signed and they totally rely on TLS for their security.

This is also included in SSL Sniff

Stripping the NULL character is not the solution. Some CA’s are vulnerable sitekey.ba\0nkofamerica.com becomes sitekey.bankofamerica.com.

http://www.thoughtcrime.org

When asked, Moxie confirmed that Firefox 3.5 is NOT vulnerable.

moxie@toughtcrime.org

“In a laboratory experiment, researchers found that between 55 percent and 100 percent of participants ignored certificate security warnings, depending on which browser they were using (different browsers use different language to warn their users).

“Everyone knew that there was a problem with these warnings,” said Joshua Sunshine, a Carnegie Mellon graduate student and one of the paper’s co-authors. “Our study showed dramatically how big the problem was.” …

The researchers first conducted an online survey of more than 400 Web surfers, to learn what they thought about certificate warnings. They then brought 100 people into a lab and studied how they surf the Web.

They found that people often had a mixed-up understanding of certificate warnings. For example, many thought they could ignore the messages when visiting a site they trust, but that they should be more wary at less-trustworthy sites.

“That’s sort of a backwards understanding of what these messages mean,” Sunshine said. “The message is validating that you’re visiting the site you think you’re visiting, not that the site is trustworthy.”