Hacker News new | past | comments | ask | show | jobs | submit login

> TLS 1.3 no longer supports RSA

This isn't entirely true, is it?

AFAICT it no longer supports RSA as a key-exchange algorithm as earlier versions did, but it certainly supports RSA authentication. The only systems that used that for TLS I've known in the last 15(ish) years were government systems that specifically wanted to prevent PFS in their logged connections.






According to the F5 telemetry report (and my own anecdotal evidence), non-PFS suites were a lot more popular than that, the majority as little as 5 years ago :-)

[0]: https://www.f5.com/content/dam/f5/f5-labs/articles/20180423_...


Definitely. There are loads of EDCO people in that data.

(EDCO is Nalini Elkins' outfit, the Enterprise Data Centre Operators group - banks and that sort of thing, they tried pointlessly lobbying the TLS Working Group to get RSA Key Exchange back into TLS 1.3)

I don't have very good contacts inside that industry any more (I now work for a startup) so I'll be interested to see what if anything they _actually_ do about this over the medium term. Trying to promote "alternatives" to TLS? Deploying DH where the "random" private values are actually from a fixed or pseudorandom source under their control? No idea yet.

It is definitely true that some big name real world "security" companies will go out to a big corporation and tell them to mandate RSA key exchange in order to make the "security" product work because they want to do MITM. They're too cheap to do all the engineering to actually ship the session keys over the wire so they want you to just upload the RSA Private Key into their "security" product.

I got this mandate to require RSA Key Ex (at my old job for a B2B app I wrote) and was like "That ain't going to work, this here is a mutually authenticated TLS session". And I ended up in a bunch of calls in which more and more senior people from the "security" product team were brought on until they eventually found someone who actually knew how it works to say that yes, of course you can't MITM a mutually authenticated session without assistance from both parties, so the product can't work.


Total agreement re: groups of bigcos trying to sabotage TLS, but I think a lot of traffic was de facto using RSA because of default configurations, not because of a serious mandate. Otherwise, I don't think you'd see such a PFS uptake in the last 5 (as opposed to 15) years.

Current status is eTLS which, if I understand it correctly, is just static DH. Unclear why nobody isn't just disclosing session keys/premaster secrets per SSLKEYFILE, but my money is "organizational incompetence" (as yours is, I'm guessing from your B2B app experience :-)).

[0]: https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/...


Disclosing secrets per session requires a lot more work on the endpoints. Especially because it is an active service. That also leaves a lot more attack-surface on the end-points. It also creates quite a bit of sensitive network traffic. Things get more hectic if you want 'live' TLS-inspection.

As such, I can definitely see why TLS inspectors don't like the myriad of opportunities for mistakes created by disclosing secrets at the end-points.

The counter-argument would be that, if you really need TLS-inspection your security should be tight enough that disclosing the secrets should not be the hardest thing you are implementing. Moreover, neither should the world compromise its own encryption to make your targeted (and rarely required) ability to break encryption safer.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: