121–130 of 237 posts
Earlier quoted context omitted.
SSL 42-started studying security in mid 90s as a teen started working 2000
Ah yes, it was a grand time, freeform studying IT security as a teen in the 90s!
Earlier quoted context omitted.
A Chicago dog is literally a hamburger with a different surface area. Same obscure ground beef, same vegetables, same bread. Just different dimensions. Who cares about the details, right?
I don’t know of anyone who puts celery salt on a hamburger.
Curious, when you tell someone they need to access a website securely (or any other case where you might use the term TLS or SSL), do you: 1. Say SSL or TLS? 2. How old are you (or did you start working before 1999?) I'll reply with my answer too.
I usually say SSL, because it has a greater chance of being understood than the more correct TLS (nobody uses SSL 3.0 anymore). It's also in the name of many SSL (I mean, TLS) libraries, like the classic OpenSSL. But yeah, I learned about SSL back in the crypto wars days of the 1990s, back when you had to pirate the so-called "US only" version of Netscape if you wanted decent SSL encryption, so I might be just using…
There are still more than 300,000 services on the Internet that support SSLv2: https://www.shodan.io/search/report?query=ssl.version%3Asslv... And a trend line of how it's changed: https://trends.shodan.io/search?query=ssl.version%3Asslv2#ov... It has dropped significantly though over the years but it will continue to stick around for a while.
But how many clients are still using it? As far as my understanding goes, no relevant, up to date piece of software/library still supports
If you look around you'll find services, today, that haven't been upgraded in decades.
Oh wow, I just discovered that my brain unconsciously had a hard time to differentiate between SSL and TLS. And now, after two friggin decades I find out, why!
Earlier quoted context omitted.
> Each of these protocols has been designed so that you could automatically negotiate versions, thus allowing for clients and servers to independently upgrade without loss of connectivity. And ensuring decades of various downgrade attacks
The downgrade attacks on TLS are only really present in the case of client behaviour where, on failing to achieve one version, they retry a new connection without it. This was necessary to bypass various broken server side implementations, and broken middleboxes, but wasn’t necessarily a flaw in TLS itself. But from the learnings of this issue preventing 1.2 deployment, TLS 1.3 goes out of its way to look very simila…
The handshake is unencrypted so you can modify the messages to make it look like the server only supports broken ciphers. Then the man in the middle can read all of the encrypted data because it was badly encrypted.
A surprising number of servers still support broken ciphers due to legacy uses or incompetence.
Earlier quoted context omitted.
Moreover, there's not really much in the way of choices here. If you don't have this kind of automatic version negotiation then it's essentially impossible to deploy a new version.
You could deploy a new version, you'd just have older clients unable to connect to servers implementing the newer versions. It wouldn't have been insane to rename https to httpt or something after TLS 1.2 and screw backwards compatibility (yes I realize the 's' stands for secure, not 'ssl', but httpt would have still worked as "HTTP with TLS")
The situation is additionally confused by the fact that the version numbers do not give a good clue to how different the protocols were. Specifically: SSLv2 was the first widely deployed version of SSL, but as this post indicates, had a number of issues. SSLv3 is a more or less completely new protocol TLS 1.0 is much like SSLv3 but with some small revisions made during the IETF standardization process. TLS 1.1 is a r…
> Each of these protocols has been designed so that you could automatically negotiate versions, thus allowing for clients and servers to independently upgrade without loss of connectivity. And ensuring decades of various downgrade attacks
If you fell under one of those exceptions, you could get a special certificate for your website (from, e.g. Verisign) that allowed the webserver to "step up" the encryption negotiation with the browser to stronger algorithms and/or key lengths.
Wait, but didn't TLS 1.0 have significant improvements over SSL 3.0? The article makes it seems that just a couple of things were tweaked just to make it different for the sake of being different.
The main difference is in the padding. When the POODLE attack was pre-announced as only affecting SSL3 and not TLS1.0, that was enough to predict it was going to be a padding oracle. I think it’s fair to say they’re very similar, with a few “bug fixes”. It’s been a while since I’ve thought about either though, and might be forgetting a few things. I’ve only ever implemented SSL3 and TLS1.0 together, so there may be s…