SSL Was Broken by Design
SSL is not secure
Date: Sat, 01 Oct 2011 08:11:15 -0400
From: William Allen Simpson <william.allen.simpson[at]gmail.com>
To: cryptography[at]randombit.net
Subject: Re: [cryptography] SSL *was* "broken by design"
On 20/09/11 01:53 AM, Andy Steingruebl wrote:
SSH doesn't solve phishing either. Is it a total failure also? I don't think so. SSL is used for a lot more than HTTPS. Any proposal to "fix" it *must* take that into account. - Andy
> Irrelevant, because SSH at the architectural level and SSH at the protocol level are aligned and in balance. There is no discord because SSH was never really taken out of its intended design framework. That's arguably because the designer wasn't facing the
>political forces of the times, which the designers of SSL drowned in. For whatever reasons, we can skip that and look at the results: SSH was pretty much always used in accordance with its original design-assumptions, whereas SSL was pretty much never used
> in accordance with its original design-assumptions.
On 9/20/11 12:51 PM, ianG wrote:
Actually, SSH faced a lot of the same political pressures as SSL. SSH didn't cave! Instead, they carefully did all the work by non-US persons outside the US -- even though that meant some foreign developers of OpenSSH had to drive across the US border into Canada.
Meanwhile, back when Netscape was located near the Stanford campus (an easy walk from the computing center), Paul Mockapetris got me to visit. I sat down with Taher Elgamal and others, explaining what we were doing with Photuris.
To the best of my memory, we thought it would be better to:
1) Authenticate the list of supported methods/transforms. We did that in Photuris to avoid MITM attackers choosing the lowest common denominator. And not only the parameters, but the length fields of the parameters, too. [Phil] Karn had insisted on cheap Photuris renegotiation from the start, and that requires protection against substitution.
2) Hide the certificates/users. We called that "party privacy protection". We used the initial D-H exchange to create a temporary stream key, and "masked" the data with the stream (simply an MD5 hash).
3) Require Perfect Forward Secrecy. We'd not managed to get IPsec to do that. It was a big argument at the time. Even today, not all TLS suites provide PFS.
4) Authenticate outside of encryption, so we could quickly and cheaply check before doing a more computationally intensive decryption. We managed to force that into IPsec, and hoped to get Netscape to do the same for SSL (now TLS). IIRC, that's since been proven to be more secure, but we didn't know it at the time. We were mostly interested in practicality.
So how was it that Netscape SSL had exactly the same faults as IPsec, ISAKMP, Oakley, IKE? Political pressure! Somebody really REALLY wanted to be able track users and intercept/substitute....
Do I have proof? No, it's merely circumstantial. Also, my multi-year FBI personal investigation over PPP CHAP was coincidental, too.
Netscape caved, for their commercial interests. There was also the CA business model. User's own interests took last place.
So, arguing about ease of use is a waste of time, as long as the easy to use protocol was designed to be broken. It really is time to start over.
If you are not a tech, you might wonder what this exchange is about. Essentially, it means the government and some astute hackers can break HTTPS which uses SSL for secure transactions.
These security protocols are used in Virtual Private Networks (VPN) and for credit card transactions.
Essentially the US government, NSA in particular, insists on a backdoor to all security protocols used on the Internet.
If you are using a VPN, make sure the provider is in Canada, Sweden, Russia or another country that does not have a reciprocity agreement with the US. This will prevent the police from using a subpoena to get server logs on your Internet activity.
This will keep the local and state police out of your PC, but not the federal government (Homeland Security/FBI or NSA). However, the Patriot Act allows the federal , state and local government to communicate freely and these organization operate with combined task forces.
Subscribe to the Rightardia feed: http://feeds.feedburner.com/blogspot/UFPYA Netcraft rank: 6627 http://toolbar.netcraft.com/site_report?url=http://rightardia.blogspot.com
Rightardia by Rightard Whitey of Rightardia is licensed under a Creative Commons Attribution 3.0 Unported License.
Permissions beyond the scope of this license may be available at rightardia@gmail.com.
