131–140 of 237 posts
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 think the TLS v1.2 pushed me that way
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…
One of the many things it brought is session tickets, enabling server-side session resumption without requiring servers to keep synced-up state. Another is Server Name Indication, enabling servers to use more than one certificate.
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!
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.
2. I’m old enough to remember 56-bit SSL encryption in browsers
Earlier quoted context omitted.
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")
> It wouldn't have been insane to rename https to httpt or something after TLS 1.2 and screw backwards compatibility That would have been at least little bit insane, since then web links would be embedding the protocol version number. As a result, we'd need to keep old versions of TLS around indefinitely to make sure old URLs still work. I wish we could go the other way - and make http:// implicitly use TLS when TLS…
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.
Nobody ever says "TLS Certificate". It's only an "SSL Certificate". On that alone, it's just easier to stick to "SSL" for consistency and everyone knows what you mean.
People who make a strong distinction between TLS and SSL are indicating that they know the difference and think you should too, but at a practical level it's the difference between .doc and .docx (fundamentally different but interchangeable to the layman). The boots on the ground mostly care about getting https to work and have minimal consideration for it's inner workings.
Earlier quoted context omitted.
Same. I feel so dumb now. After 15 years in this industry i finally figured out that ssl and tls are the same.
No no, they're not. They're names of specific protocols with specific capabilities and versions. "SSL 1.0" and "TLS 1.0" are very different. (see https://aws.amazon.com/compare/the-difference-between-ssl-an... ) The important bits: - "SSL" is a set of protocols so ridiculously old, busted and insecure that nobody should ever use them. It's like talking about Sanskrit; ancient and dead. - "TLS" is way better than "SSL…
Earlier quoted context omitted.
> But Netscape in this instance acted like kids Oh, please. https://en.wikipedia.org/wiki/Criticism_of_Microsoft The "velvet sweatshop" one is sufficient, but plenty of others to choose from. Don't have a source at hand but I remember it was known for its "work 3 years there and then you need to retire early from burnout" culture. There's also a really good (and highly depressing) 2001 German documentary around that…
You quoted "in this instance" and then cited completely unrelated problems?
Some companies make abuse a business model. I don't see how anyone can defend a position where they only look at isolated actions of a company and not their overall strategic positioning. There are boundaries. Ethical boundaries. If you never experience the consequences of your actions, if nobody ever objects to your behavior, you will not stop. Especially not a distributed organism of a company, which has no inherent ethical boundaries; its boundaries are those that affect business, so you need to teach them in business. If your business model is based on treating your own employees like slaves, it is you who is cancer, not the other.
Calling that “kid-like behavior” is misguided on two levels. First, as noted, Netscape’s actions were arguably rational in context - pushing back against a powerful incumbent trying to steer an open standard toward a proprietary implementation.
Second, the phrase itself leans on a dismissive and inaccurate stereotype. Kids aren’t inherently irrational or overly emotional; in fact, there’s substantial research showing that young people behave quite logically given their environment. Framing behavior this way isn’t just lazy; it reinforces the kind of condescension that later gets labeled as “adverse childhood experiences” in therapy, assuming someone even gets the chance to unpack and not replicate it.
On both levels, it is DARVO.
Earlier quoted context omitted.
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…
Man in the middle interfering with TLS handshakes? 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.