A few days ago while starting TortoiseSVN it prompted me to update to version 1.7
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:
-
Fragility of the trust ecosystem
-
Incorrect or weak configuration
-
Slow adoption of modern statndar
-
Lack of support for virtual SSL hosting
-
Mismatch between HTTP and SSL
There are three main attacks against SSL:
Active MitM
Third party compromise
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.
Read more…
Today I presented about the TLS regenotiation vulnerability I blogged about earlier.
You can download the slides below:
Special thanks to Marsh Ray for his suggestions and corrections.
Three days ago on the 3rd of November Marsh Ray and Steven Dispensa of PhoneFactor released a whitepaper that describes a man in the middle attack against TLS and SSL v3 by using the “renegotiation” feature of the protocol. Let there be no mistake, this is a limited, but still serious attack.
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.
Read more…
Categories: Security, SSL Tags: Attack, cross site request forgery, CSRF, Dan Kaminiski, e-commerce, https, Man in the Middle, Marsh Ray, Mike Zusman, Mitm, Moxie, Moxie Marlinspike, Online Banking, OpenSSL, renegotiation, request smuggling, Security, SSL, Steven Dispensa, TLS, TLS renegotiation, XSRF
Moxie Marlinspike, Dan Kaminski and Mike Zusman all presented talks at both Blackhat and Defcon that expose serious flaws the implementation and model of SSL and the way we us it today.
Read more…
Categories: Blackhat, Conferences, Defcon Tags: Blackhat, CA, certificates, Citrix, Dan Kaminski, Defcon, DNS, DNSSEC, Maxie Marlinspike, Mike Zusman, Security, SSL, Thrust, VPN
The background: In the past, basic constraints where not properly checked, so any client certificate could be used to create another client certificate that would actually validate.
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
Read more…
As reported here: http://www.goodgearguide.com.au/article/312438/security_certificate_warnings_don_t_work_researchers_say
“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.”
