Hacker News Reader

Comment by akerro | Hacker News Reader

Also, remember to never search for pressure cookers and backpacks led if you want to save yourself some troubles and prevent being listed on the watchlist another time (you're already there, yes you, you Linux user!)

https://www.theguardian.com/world/2013/aug/01/new-york-polic...

View on HN

> Suffolk County criminal intelligence detectives received a tip from a Bay Shore-based computer company regarding suspicious computer searches conducted by a recently released employee.

So I guess don't do that if you work for someone who's going to send the police to your house over it after they fire you? Not sure there's really a larger point to be made here about watchlists, surveillance, or indeed anything, considering the only element of that story which couldn't happen in 1930 is the part about Google.

Was 2013 before all Google searches were secure? Unless your workspace is doing MITM they wouldn't see the search now. Though, obviously you'd have to trust that Google wouldn't dob you in either.

I thought it's standard practice to MITM at the workplace. How else can you flag exfiltration of sensitive information and stop incoming malware? Add a certificate to browsers on employee's computers, encrypt on proxy after inspection.

This still breaks TLS, since it will fail with client-supplied certificates and so can't be used if you need to support TLS.

Computers owned by the firm have extra CAs installed. All browsers allow admins to add CAs. Unsophisticated users will never know that e.g. BlueCoat shitboxes (and everyone who has pwned those shitboxes) are reading all their TLS traffic.

But the web servers on the other side of the TLS connection are not managed by those same system administrators and therefore they will not accept certificates provided by such proxies, breaking TLS.

To the external server, the shitbox is the user. To the user, the shitbox is the external server. Talk to IT/Networking people at any large firm; this is how it has worked for years.

Client certs are a different thing entirely, and unrelated to this discussion.

How are client certificates, a mandatory feature of TLS and specifically what I mentioned, and what you are replying to, unrelated to this discussion ?

What is this "mandatory feature" stuff? We're talking [0] about employees on websites "protected" by TLS, and expecting privacy while doing so. If they order hemorrhoid cream on Amazon, their browser talks to the shitbox, the shitbox talks to Amazon, and client certs have nothing to do with that. The browser verifies that it trusts the shitbox, and nobody else verifies anything.

One supposes there might be some banks or B2B sites that might use client certs, but they're such a minority that no one ever heard of them.

[0] https://news.ycombinator.com/item?id=16186735

Client certificates are a mandatory feature of TLS that any TLS server could request and the proxy would be unable to handle the request, as it (and ideally the client) has no access to the private key. Therefore, these types of proxies break TLS by being unable to support mandatory features.

Separate from that, client certificates are certainly common, being used for authentication, in the US Federal Government, which issues tens of millions of certificates for this purpose as well as smartcards, since George W. Bush banned passwords with HSPD-12.

The shitboxes definitely "break" TLS. That's why firms buy them in the first place. A firm that was using smartcards with the characteristics you describe would presumably figure out something other way to pretend to prevent data exfil.

I've literally in a 25 year IT career only worked at one place which did TLS MITM, and that's a place that works extensively with GCHQ.

that watch list must've gotten really long thanks to the instant pot craze...

Now someone just needs to make a backpack designed to carry the Instant Pot.

Reply on news.ycombinator.com