Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

How does TLS disable anonymous access? My identity and/or location is not a single bit more exposed than it already is when I access a site either with or without TLS. There are indeed authority and centralization issues with the current CA system, but again, it has nothing to do with my anonymity.

Meanwhile, caching is such an overused and undersubstantiated argument that it's not even funny anymore. How many websites you recently visited was served by a cache operated by anyone other than the same party who owns the website, or a CDN that the website owner trusts enough to let them have the TLS keys? Are untrusted proxies (read: MITM as a service) such an integral part of the web that we must keep them alive at any cost?

There are decent reasons to eschew TLS for public information -- for example, PGP signatures that can be verified out-of-band are much cheaper for large blobs of static data such as .deb packages -- but anonymity and caching are not among them.



Perhaps he is referring to TLS Session Resumption which might be a form of cookie (as it identifies the user across sessions).

But it still hides what you are transferring from anyone observing the traffic.


Maybe, but currently some site today can set a cookie in your browser and track you anyway -- a lot simpler than fiddling with the TLS stack.

I assume that if you browse in "Private Browsing" or "Incognito" mode, then the TLS Session Resumption data is wiped once you exit that mode (similar to how cookies and local storage is wiped).


The site you visit yes. But I am referring to a MITM. A cookie would be hidden by the secure tunnel. But the TLS resemption parameters might be visible as it happens before the tunnel is established. I am not familiar enough with the protocole to know if it is the case.


The resumption parameters might be used to uniquely identify a person... that's an interesting point.

But is that a big enough flaw to justify throwing out the baby of TLS with the bathwater of tiny details like that? I'm sure there are people who are much smarter than both of us who can fix that without giving up on TLS altogether.


I agree with you, certainly not. But I was trying to understand his argument.


Ah, I see. Yes, from a cursory glance at RFC 5077, it seems that the SessionTicket is sent as part of ClientHello, which is not encrypted (page 6).

This is still no worse than plain unencrypted HTTP at worst, and server admins or clients could well choose not to support this if they do not wish to.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: