Hacker News Reader

Comment by jiofih | Hacker News Reader

Is there any point in encrypting API payloads when the traffic is going via TLS?

Potentially to prevent MITM proxies on company computers from being able to sniff the traffic. Maybe because of what blind is about, that would make sense? Otherwise, if it's secure TLS, then no reason at all

Edit: maybe the reason they use public key for transmission is because you can't reverse that, and that would potentially be where your anonymous complaints your complaints (or whatever you do on blind) would be?

Note that as thenewnewguy says, anyone who can MITM your connection can also inject JS spyware (well, more so than usual) to exfiltrate your comments. That's harder (and much harder still to avoid discovery) than just sniffing the traffic, so it might be a useful stopgap, but for real security you need to fix your web browser to reject MITMed connections.

Security through obscurity. Pretty sure Blind did this just to piss off scrapers. I mean I've been scraping them for some time until they pulled this encryption trick about a year ago. I didn't have time to reverse engineer their js and keep my scraper up to date, that'd take way more time than it took me to write some 100 lines to scrape them originally. So score 1 for them.

For blind? yes. It is designed to be anonymous from your employer. Many employers, especially those for which employees would enjoy anonymous complaining, have TLS-intercepting middleboxes.

How would that work, unless the Blind posters are posting from corp-managed phones which have company-signed certs installed?

lots of places use an MDM profile if you connect to work email, for instance.

This kind of deep packet inspection is in no way limited to phones.

sure, my point was really: there's no way for your employer to intercept the packet contents unless they've got their own cert bundle installed, and you'd have to be pretty clueless to use this from a corp machine of any kind.

most people are in fact clueless.

Reasons I can think of: depends whether you assume TLS is not going to be broken again and whether the TLS termination happens before the component you want to process the data, to do any sort of check, e.g., web application firewall. With the goal of reducing insider threat and reducing exposure of sensitive data to components that don't need to know such data. However usually it's a bad idea to solely rely on javascript crypto: https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

In theory: no, because anyone able to break the TLS could just slip in some JS to capture your comments.

In practice: possibly, because many companies use TLS proxies that probably aren't doing that?

If your API goes through a CDN you don't fully trust.

Reply on news.ycombinator.com