201–210 of 237 posts
Earlier quoted context omitted.
> M$ (appropriate name for that time) It’s even more appropriate nowadays, I’d say.
Never not been appropriate.
“Transport Layer Security” really is a better name though. I also like to say “TLS”. Two Ses in a row makes you sound like a snake.
I think SSL is a better fit, actually. In theory TLS could be a transport-layer security mechanism that would let arbitrary protocols run on top of it (like IPSec does), but in practice it's pretty much tied up to TCP sockets. The UDP variant (DTLS, and I suppose QUIC) isn't part of the TLS spec for instance. Of course we have kernel TLS on Linux now, and Windows also has infrastructure like that, but it isn't as eas…
I like to imagine an alternate past where ipsec "won" and how that would affect our expectations of secure connections. One thing different is that the security would handled at the os level instead of the application level, on the one hand this is nice all application get a secure connection whether they want one or not, on the other hand the application has no idea it is using a secure transport and has no way of indicating this to the user.
Anyhow the opportunistic connection employment of ipsec never really got implemented and all we use it for anymore is as a dedicated tunnel. one that is fiendishly difficult to employ.
I think the primary problem with ipsec is that it tried to be too flexible. this made setting up a ipsec link a non-trivial exercise in communication, and the process never got streamlined enough to just be invisible and work.
Earlier quoted context omitted.
That’s a great theory but in practice such a “flag day” almost never happens. The last time the internet went through such a change was January 1, 1983, when the ARPANET switched from NCP to the newly designed TCP/IP. People want to do something similar on February 1, 2030, to remove IPv4 and switch totally to IPv6, but I give it a 50/50 chance of success, and IPv6 is already about 30 years old. See https://ipv4flagd…
You don't have to have everyone switch over on the same day as with your example. Once it is decreed that implementations are widespread enough, then everyone can switch over to the introduced thing gradually. The "flag day" is when it is decreed that implementations no longer have to support some previously widely used method. Support for that method would then gradually disappear unless there was some associated cr…
1. You actually get benefit during the transition period because you get to use the new version.
2. You get to test the new version at scale, which often reveals issues, as it did with TLS 1.3. It also makes it much easier to measure deployment because you can see what is actually negotiated.
3. Generally, implementations are very risk averse and so aren't willing to disable older versions until there is basically universal deployment, so it takes the pressure off of this decision.
Considering that Microsoft was a completely different beast in that time, I'm not surprised it does not seem that silly. M$ (appropriate name for that time) of the day was doing its best to own everything and the did not let up on trying to hold back the open source internet technologies until the early 2010's I believe. Its my opinion that they were successful in killing Java Applets, which were never able to improv…
I had high hopes for s2n, but looks like it never really caught on outside of AWS.
“Transport Layer Security” really is a better name though. I also like to say “TLS”. Two Ses in a row makes you sound like a snake.
The problem is that TLS was already in widespread use for "thread local storage". Transport Layer Security is widely documented as beginning in 1999. I can find references to "Thread Local Storage" going back to at least 1996. That particular term seems more common in the Microsoft (and maybe IBM, does anyone have an OS/2 programming manual?) world at the time; Pthreads (1995) and Unix in general tended to call it "t…
Without reading the article, is the reasoning similar to how the USB consortium chooses numbers and names?
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.
Well you can , but that would require a higher level of political skill than normally exists for such things. What would have to happen is that almost everyone would have to agree on the new version and then implement it. Once implementation was sufficiently high enough then you have a switchover day. The big risk with such an approach is that you could implement something, then the politics could fail and you would…
Part of the motivation of TLS 1.3 was to mitigate that. It removed a lot of options for negotiating the ciphersuite.
Earlier quoted context omitted.
Are there any real world online resources where, modulo redirect, a different resource is presented on the HTTP and the HTTPS protocols? Or alternatively, on ports 80 and 443?
There used to be, though it's less true now. However, the reason to treat them distinctly (as different origins, technically) is that HTTPS provides integrity whereas HTTP does not. So, consider the case where the client enters an HTTP URL and is redirected, just as you say above. If the attacker injects their own JS and it is cached in an origin that is just `example.com`, then they control the user's experience of…
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…
Wouldn't we be able to just redirect https->httpt like http requests do right now?
Sure it'd be a tiny bit more overhead for servers, but no different than what we already experienced moving away from unencrypted http
Earlier quoted context omitted.
You could encrypt the handshake that you recieved with the server's certificate and send it back. Then if it doesn't match what the server thought it sent it aborts the handshake. As long as the server's cert isn't broken this would detect a munged handshake, and if the server's cert is broken you have no root of trust to start the connection in the first place.
How do you agree a protocol to encrypt the message to agree the protocol? This is the message that returns a list of supported ciphers and key exchange protocols. There’s no data in this first packet. Alice: I’d like to connect Bob: Sure here is a list of protocols we could use: You modify bob’s message so that bob only suggests insecure protocols. You might be proposing that Alice asks Trent for Bob’s public key … B…
If the "negotiated" cipher suite is weak enough to allow real-time impersonation of Bob, though, pre-1.3 versions are still vulnerable; that's another reason not to keep insecure cipher suites around in a TLS config.