4 ms·

If your stance is: No opaque data leaves my network Then this is the only way you can have outbound HTTPS connections. And for e.g. a bank, certain legal firm

by rocqua 8y ago

If your stance is: No opaque data leaves my network Then this is the only way you can have outbound HTTPS connections. And for e.g. a bank, certain legal firms, or any company that has a lot of sensitive data they either don't want to be leaked, or at least want the option of detecting when it is leaked, that is a somewhat reasonable stance. In the case of banks, this is needed for regulatory compliance regarding insider trading. For legal companies, I imagine this is about ensuring certain confidentiality. I could see the same thing for companies dealing with trade-secrets. The statement 'Just log it on the end-points' presumes complete access to those end-points and all software running on them. This method is considered better than terminating TLS early at a proxy and setting up a separate tunnel to the clients because breaking PFS is passive, rather than active. Thus it is a lot less resource intensive, a lot less vulnerable (no internet facing box that, if broken, has all communication in plaintext), and introduces no extra latency. It is essentially a 'better' way to do an authorized MitM on everything on your network, and some companies want this authorized MitM. Like any authorized MitM, it introduces a third party who can compromise security, which is not generally desirable, but some companies don't mind being that third party to their own employees.

tinus_hn 8y ago
It’s a pipe dream. The webpage or application can easily include its own encryption that can’t be broken by these proxies. If your stance is ‘no opaque data leaves my network’ your only option is an air gap.
- acdha 8y ago
  Engineering is all about making trade-offs (“perfect is the enemy of the good and all”) and security engineering is no different. The same logic could be used to say that you don't need an edge firewall because each client should have one but it's much easier to simplify the baseline. If nothing else, it would make the remaining traffic stand out more since you wouldn't be spending time auditing normal apps which decode cleanly and it's highly likely that someone trying to circumvent such a system would be required to do things which stand out more than routine usage. As a simple example, an organization which does that kind of monitoring is unlikely to allow users to install arbitrary applications or visit any site on the web. With a standard setup, someone trying to exfiltrate data could just hit a popular site like Github, Gmail, Dropbox, etc. but if they need to use some custom encryption or steganography code they're either forced to install it somewhere far less common (i.e. more likely to stand out) or installing something locally where client monitoring can report an unusual browser extension or application.
  - tinus_hn 8y ago
    A cute excuse until one of your popular sites starts to do this. Now it happens to be that Google hates these proxies as they are a popular target for repressive governments, who technically can’t be distinguished from a snooping ‘enterprise’. The reality is that world kept turning without these proxies and it will keep turning once they are made obsolete.
- AndyMcConachie 8y ago
  It's not a pipe dream if your only goal is to be compliant with a formal rule or regulatory structure that requires it. The reason we need stuff like ETS is really because there are organizations that otherwise could not allow any outbound HTTPS sessions. There are people who need to check off boxes in order to comply with certain rules. Their security reality is not actually all that important.
  - Freak_NL 8y ago
    They control the devices on their side of the firewall, so they can log whatever they want before the data sent enters the encrypted tunnel, and after the data received exits it. ETS just means they don't have to spend money on replacing their man-in-the-middle monitoring gear with client-local solutions on every workstation and server. It al seems pretty silly though. Regulators aren't idiots; they know that HTTPS is everywhere now, and that TLS 1.3 means that third parties listening in on connections are going to be thing of the past, so the regulations will change to reflect that.
    - funkymike 8y ago
      > ETS just means they don't have to spend money on replacing their man-in-the-middle monitoring gear with client-local solutions on every workstation and server. Doesn't it still require altering the TLS implementation to use the static DH keys instead of following the TLS 1.3 standard of using random keys?
- rocqua 8y ago
  You can ban the use of such applications a lot easier than you can ban HTTPS. This means that simply using those tools is grounds for legal action, which might suffice. Especially if the concern for confidentiality is not for internal reasons, but for legal reasons.
deathanatos 8y ago
Why not have the endpoints ship their session keys OoB to a centralized place / whatever needs to look at the traffic? Sure, there's more of them, but that shouldn't be a huge volume? (It is insignificant compared to the captured traffic.) > The statement 'Just log it on the end-points' presumes complete access to those end-points and all software running on them. There still has to be some control over the endpoints. Otherwise, what prevents them from negotiating an algorithm in TLS 1.2 that has PFS? And I am not sure if you're attempting to address this, but instead of terminating at a more edge-ish node, why not just decrypt and re-encrypt there? (So, it is still encrypted internally, but the node can inspect the data in an authorized manner.) (You seem to address it, but I'm not sure what you mean: yeah, having a centralized box decrypting your traffic means that an attacker that gets access to that can see a lot. But what were you doing in TLS 1.2 w/ a non-PFS ciphersuite that didn't involve a machine w/ the ability to decrypt everything?)
- cbsmith 8y ago
  > Why not have the endpoints ship their session keys OoB to a centralized place / whatever needs to look at the traffic? Sure, there's more of them, but that shouldn't be a huge volume? (It is insignificant compared to the captured traffic.) When you have communication between two endpoints, over your own network, transmitting session keys OoB doesn't improve the security of your systems, but does increase the complexity. > And I am not sure if you're attempting to address this, but instead of terminating at a more edge-ish node, why not just decrypt and re-encrypt there? Aside from adding a ton of latency and extra performance overhead, you now have a new operational endpoint that you have to trust. That doesn't fit the trust model. They key point here is the data is getting logged and then decrypted offline, by a totally separate system.
  - bmm6o 8y ago
    Not to mention that you have to trust the endpoint to ship their session keys. If one "forgets" or the key is "lost in the mail", there's no way to prove that message wasn't problematic.
    - 8y ago
SamuelAdams 8y ago
It's not just companies that want to MitM their traffic: consumers want this too. Otherwise all the IoT devices in a house will no longer be trustable: Alexa can start uploading everything it hears, even if you never said "hey alexa!". And because of forward secrecy, you can't verify what it did or did not send: it all looks the same. This expands to any IoT device with proprietary software on it, which by 2023 will be quite a lot of things.

by rocqua 8y ago

tinus_hn 8y ago

It’s a pipe dream. The webpage or application can easily include its own encryption that can’t be broken by these proxies. If your stance is ‘no opaque data leaves my network’ your only option is an air gap.

acdha 8y ago
Engineering is all about making trade-offs (“perfect is the enemy of the good and all”) and security engineering is no different. The same logic could be used to say that you don't need an edge firewall because each client should have one but it's much easier to simplify the baseline. If nothing else, it would make the remaining traffic stand out more since you wouldn't be spending time auditing normal apps which decode cleanly and it's highly likely that someone trying to circumvent such a system would be required to do things which stand out more than routine usage. As a simple example, an organization which does that kind of monitoring is unlikely to allow users to install arbitrary applications or visit any site on the web. With a standard setup, someone trying to exfiltrate data could just hit a popular site like Github, Gmail, Dropbox, etc. but if they need to use some custom encryption or steganography code they're either forced to install it somewhere far less common (i.e. more likely to stand out) or installing something locally where client monitoring can report an unusual browser extension or application.
- tinus_hn 8y ago
  A cute excuse until one of your popular sites starts to do this. Now it happens to be that Google hates these proxies as they are a popular target for repressive governments, who technically can’t be distinguished from a snooping ‘enterprise’. The reality is that world kept turning without these proxies and it will keep turning once they are made obsolete.
AndyMcConachie 8y ago
It's not a pipe dream if your only goal is to be compliant with a formal rule or regulatory structure that requires it. The reason we need stuff like ETS is really because there are organizations that otherwise could not allow any outbound HTTPS sessions. There are people who need to check off boxes in order to comply with certain rules. Their security reality is not actually all that important.
- Freak_NL 8y ago
  They control the devices on their side of the firewall, so they can log whatever they want before the data sent enters the encrypted tunnel, and after the data received exits it. ETS just means they don't have to spend money on replacing their man-in-the-middle monitoring gear with client-local solutions on every workstation and server. It al seems pretty silly though. Regulators aren't idiots; they know that HTTPS is everywhere now, and that TLS 1.3 means that third parties listening in on connections are going to be thing of the past, so the regulations will change to reflect that.
  - funkymike 8y ago
    > ETS just means they don't have to spend money on replacing their man-in-the-middle monitoring gear with client-local solutions on every workstation and server. Doesn't it still require altering the TLS implementation to use the static DH keys instead of following the TLS 1.3 standard of using random keys?
rocqua 8y ago
You can ban the use of such applications a lot easier than you can ban HTTPS. This means that simply using those tools is grounds for legal action, which might suffice. Especially if the concern for confidentiality is not for internal reasons, but for legal reasons.

deathanatos 8y ago

Why not have the endpoints ship their session keys OoB to a centralized place / whatever needs to look at the traffic? Sure, there's more of them, but that shouldn't be a huge volume? (It is insignificant compared to the captured traffic.) > The statement 'Just log it on the end-points' presumes complete access to those end-points and all software running on them. There still has to be some control over the endpoints. Otherwise, what prevents them from negotiating an algorithm in TLS 1.2 that has PFS? And I am not sure if you're attempting to address this, but instead of terminating at a more edge-ish node, why not just decrypt and re-encrypt there? (So, it is still encrypted internally, but the node can inspect the data in an authorized manner.) (You seem to address it, but I'm not sure what you mean: yeah, having a centralized box decrypting your traffic means that an attacker that gets access to that can see a lot. But what were you doing in TLS 1.2 w/ a non-PFS ciphersuite that didn't involve a machine w/ the ability to decrypt everything?)

cbsmith 8y ago
> Why not have the endpoints ship their session keys OoB to a centralized place / whatever needs to look at the traffic? Sure, there's more of them, but that shouldn't be a huge volume? (It is insignificant compared to the captured traffic.) When you have communication between two endpoints, over your own network, transmitting session keys OoB doesn't improve the security of your systems, but does increase the complexity. > And I am not sure if you're attempting to address this, but instead of terminating at a more edge-ish node, why not just decrypt and re-encrypt there? Aside from adding a ton of latency and extra performance overhead, you now have a new operational endpoint that you have to trust. That doesn't fit the trust model. They key point here is the data is getting logged and then decrypted offline, by a totally separate system.
- bmm6o 8y ago
  Not to mention that you have to trust the endpoint to ship their session keys. If one "forgets" or the key is "lost in the mail", there's no way to prove that message wasn't problematic.
  - 8y ago

SamuelAdams 8y ago

It's not just companies that want to MitM their traffic: consumers want this too. Otherwise all the IoT devices in a house will no longer be trustable: Alexa can start uploading everything it hears, even if you never said "hey alexa!". And because of forward secrecy, you can't verify what it did or did not send: it all looks the same. This expands to any IoT device with proprietary software on it, which by 2023 will be quite a lot of things.