4 ms·

But even then, my work network for example decrypts traffic or if it can't blocks it.

by 7ewis 7y ago

theamk 7y ago
Yeah, in those environments you may have no choice. But in my case, many local hospitals have free WiFi which blocks everything "suspicious", including most of UDP and many VPN-related TCP ports.
Wheaties466 7y ago
Thats not incredibly uncommon either but i've always wondered how companies get away with decrypting certain sites, i.e. Healthcare. I don't know if it would be appropriate for me to comment further as I work for a middlebox provider.
- gervase 7y ago
  > i've always wondered how companies get away with decrypting certain sites, i.e. Healthcare. Often, through some kind of employee code of conduct; think along the lines of "I agree to refrain from using my work computer for personal business." or similar. Then, if something sensitive is decrypted, the employer has some legal cover.
  - pnutjam 7y ago
    In my experience, those aren't decrypted. I see company generated certs for most https, but not banks and healthcare sites. I'm guessing there is some sort of whitelist.
- tialaramex 7y ago
  Techniques available: IP address matching: Watch raw IP layer, pass through TLS traffic to some IP range, this requires vigilance to ensure the IP range maps well to the set of sites you're OK not decrypting and doesn't include sites you want to decrypt. SNI matching: During TLS ClientHello watch the SNI provided by the client, if it's on a whitelist, let the entire connection through. Clients aren't obliged to be honest and servers aren't required to even look at SNI, if they serve only a single site why check? Certificate CN/ SAN matching: Stall during TLS ClientHello, wait for the responding ServerHello and Certificate from the server, and examine the certificate for a hostname, check if it's whitelisted. Otherwise, decrypt the connection. That last technique is very popular, and real middlebox companies (e.g. Cisco) have argued that since it doesn't work in TLS 1.3 (the Certificate message is encrypted so they can't read it) this is a significant security-relevant change. In the rant below I will show how to bypass this "security" check mostly because it is useless, companies selling it have been selling snake oil. Either they're too stupid to know it doesn't work or they assume their customers are too stupid, either way why would you deal with a "security" company like that? 1. Certificate contains only public documents, one or more X.509 certificates. Bad guys can get Google's certificate, or that of a bank, STI clinic or government regulator by simply connecting to those outfits and gathering the certificate. 2. The legitimate _client_ (e.g. your web browser) will need proof that the web site knows the Private Key corresponding to the public key in the certificate, but that proof is encrypted, either implicitly (RSA key exchange sends the session keys encrypted with the public key) or explicitly (modern cipher suites present an encrypted public key proof of ownership for the session) and so a middlebox can't see it except by interposing and decrypting everything. 3. Thus a "rogue" client can just connect to a "rogue" TLS endpoint and send SNI for www.google.com [pick any whitelisted hostname here], the server sends back a Certificate message for www.google.com and then the client just ignores the public key inside that certificate and presses on using a defined public key for the rogue server. The middlebox cannot detect this happening, regardless of whether TLS 1.3 or earlier are used, it works the same and the "security" features in the middlebox don't prevent it. Again, middlebox vendors have been _told_ about this, they either aren't bright enough to understand it (so you should not trust them) or they are lying to customers in the hope the customers don't understand it (so you should not trust them) and either way the result is the same.
  - indigo945 7y ago
    > The middlebox cannot detect this happening, regardless of whether TLS 1.3 or earlier are used, it works the same and the "security" features in the middlebox don't prevent it. Can't the middlebox just connect to the same endpoint, verify the certificate itself by checking that it is signed by a proper CA, and then, if it is not, drop the connection?
    - tialaramex 7y ago
      "Checking that it is signed by a proper CA" isn't relevant, the certificate presented is the real one, like I said they're public documents, there's no reason to use fakes. But the middlebox can, indeed, verify that when it connects to this same (IP, port) pair that endpoint is able to prove it's the real thing. I have never seen one that does this, and it won't prove anything about other connections, since our "rogue" TLS server can proxy everything to the real whitelisted server and that will pass, but yes you could do that. You can invent arbitrarily sophisticated schemes and counter-schemes in this space. The 32 bytes of ClientHello random in particular mean you can never tell whether the client is signalling to the server or not if you even sometimes choose not to interpose.
dspillett 7y ago
Well yes, that would block this. But we've now flipped from "why not use X instead of Y" "because some networks block Y" to "X is still bad because my network would block it". Your network doesn't make it a bad choice for his/other networks! There will no doubt be a way to get around your networks propensity to block traffic that looks encrypted, though we are getting very specific to that circumstance in order to do so. Perhaps using actual valid HTTP protocol on port 80 to send and receive data via POST requests (polling for receive if there is nothing to send) would be sufficient, though not efficient. If not then you could try hide the encrypted traffic inside what looks like plain text, maybe sending book passages and flipping between upper and lower case to represent 1 & 0 bits... Though of course any human looking at packets that are part of the stream are going to see that you are trying to hide something, though that would be a problem with all these techniques.
the8472 7y ago
you could have an outer TLS tunnel that accepts the MITM certificate, then do HTTP, then a websocket upgrade then your VPN-over-websocket. Or fake pipelined HTTP that exchanges data bidirectionally. But really, you don't have internet access at that point, so you shouldn't expect internet software to work.
indigo945 7y ago
The software Shadowsocks (and its variants), developed by a Chinese hacker to circumvent the Chinese internet censorship, may be of some use here. It is able to tunnel all packets through a seemingly legitimate HTTP connection, which can be used to fool automated traffic snooping attempts.

But even then, my work network for example decrypts traffic or if it can't blocks it.

by 7ewis 7y ago

But even then, my work network for example decrypts traffic or if it can't blocks it.

Yeah, in those environments you may have no choice. But in my case, many local hospitals have free WiFi which blocks everything "suspicious", including most of UDP and many VPN-related TCP ports.

Wheaties466 7y ago

Thats not incredibly uncommon either but i've always wondered how companies get away with decrypting certain sites, i.e. Healthcare. I don't know if it would be appropriate for me to comment further as I work for a middlebox provider.

gervase 7y ago
> i've always wondered how companies get away with decrypting certain sites, i.e. Healthcare. Often, through some kind of employee code of conduct; think along the lines of "I agree to refrain from using my work computer for personal business." or similar. Then, if something sensitive is decrypted, the employer has some legal cover.
- pnutjam 7y ago
  In my experience, those aren't decrypted. I see company generated certs for most https, but not banks and healthcare sites. I'm guessing there is some sort of whitelist.
tialaramex 7y ago
Techniques available: IP address matching: Watch raw IP layer, pass through TLS traffic to some IP range, this requires vigilance to ensure the IP range maps well to the set of sites you're OK not decrypting and doesn't include sites you want to decrypt. SNI matching: During TLS ClientHello watch the SNI provided by the client, if it's on a whitelist, let the entire connection through. Clients aren't obliged to be honest and servers aren't required to even look at SNI, if they serve only a single site why check? Certificate CN/ SAN matching: Stall during TLS ClientHello, wait for the responding ServerHello and Certificate from the server, and examine the certificate for a hostname, check if it's whitelisted. Otherwise, decrypt the connection. That last technique is very popular, and real middlebox companies (e.g. Cisco) have argued that since it doesn't work in TLS 1.3 (the Certificate message is encrypted so they can't read it) this is a significant security-relevant change. In the rant below I will show how to bypass this "security" check mostly because it is useless, companies selling it have been selling snake oil. Either they're too stupid to know it doesn't work or they assume their customers are too stupid, either way why would you deal with a "security" company like that? 1. Certificate contains only public documents, one or more X.509 certificates. Bad guys can get Google's certificate, or that of a bank, STI clinic or government regulator by simply connecting to those outfits and gathering the certificate. 2. The legitimate _client_ (e.g. your web browser) will need proof that the web site knows the Private Key corresponding to the public key in the certificate, but that proof is encrypted, either implicitly (RSA key exchange sends the session keys encrypted with the public key) or explicitly (modern cipher suites present an encrypted public key proof of ownership for the session) and so a middlebox can't see it except by interposing and decrypting everything. 3. Thus a "rogue" client can just connect to a "rogue" TLS endpoint and send SNI for www.google.com [pick any whitelisted hostname here], the server sends back a Certificate message for www.google.com and then the client just ignores the public key inside that certificate and presses on using a defined public key for the rogue server. The middlebox cannot detect this happening, regardless of whether TLS 1.3 or earlier are used, it works the same and the "security" features in the middlebox don't prevent it. Again, middlebox vendors have been _told_ about this, they either aren't bright enough to understand it (so you should not trust them) or they are lying to customers in the hope the customers don't understand it (so you should not trust them) and either way the result is the same.
- indigo945 7y ago
  > The middlebox cannot detect this happening, regardless of whether TLS 1.3 or earlier are used, it works the same and the "security" features in the middlebox don't prevent it. Can't the middlebox just connect to the same endpoint, verify the certificate itself by checking that it is signed by a proper CA, and then, if it is not, drop the connection?
  - tialaramex 7y ago
    "Checking that it is signed by a proper CA" isn't relevant, the certificate presented is the real one, like I said they're public documents, there's no reason to use fakes. But the middlebox can, indeed, verify that when it connects to this same (IP, port) pair that endpoint is able to prove it's the real thing. I have never seen one that does this, and it won't prove anything about other connections, since our "rogue" TLS server can proxy everything to the real whitelisted server and that will pass, but yes you could do that. You can invent arbitrarily sophisticated schemes and counter-schemes in this space. The 32 bytes of ClientHello random in particular mean you can never tell whether the client is signalling to the server or not if you even sometimes choose not to interpose.

dspillett 7y ago

Well yes, that would block this. But we've now flipped from "why not use X instead of Y" "because some networks block Y" to "X is still bad because my network would block it". Your network doesn't make it a bad choice for his/other networks! There will no doubt be a way to get around your networks propensity to block traffic that looks encrypted, though we are getting very specific to that circumstance in order to do so. Perhaps using actual valid HTTP protocol on port 80 to send and receive data via POST requests (polling for receive if there is nothing to send) would be sufficient, though not efficient. If not then you could try hide the encrypted traffic inside what looks like plain text, maybe sending book passages and flipping between upper and lower case to represent 1 & 0 bits... Though of course any human looking at packets that are part of the stream are going to see that you are trying to hide something, though that would be a problem with all these techniques.

the8472 7y ago

you could have an outer TLS tunnel that accepts the MITM certificate, then do HTTP, then a websocket upgrade then your VPN-over-websocket. Or fake pipelined HTTP that exchanges data bidirectionally. But really, you don't have internet access at that point, so you shouldn't expect internet software to work.

indigo945 7y ago

The software Shadowsocks (and its variants), developed by a Chinese hacker to circumvent the Chinese internet censorship, may be of some use here. It is able to tunnel all packets through a seemingly legitimate HTTP connection, which can be used to fool automated traffic snooping attempts.