5 ms·

I just read the discussion and I see that people are conflating a few things and having an emotional response. There is a difference between different types of

I just read the discussion and I see that people are conflating a few things and having an emotional response. There is a difference between different types of network operators, and whether they have any business snooping on your traffic. There is a difference between an unauthorized party intercepting TLS communication, and a party you have authorized to do so. Let's say I am a private person and am trying to access my bank account through a TLS connection. I am connected via WiFi to my cafe. I have not authorized the cafe, its uplink provider, nor any of the other network operators between me and the bank to intercept my traffic. It should be impossible to do so. Let's say I am employee of a financial institution. This company, in order to adhere with record-keeping laws, needs to log all network connections. One of the conditions of my employment is that I authorize the company to intercept my network communications. The proxies within my company should be able to intercept my communications. However, no network operator outside of the company for which I work for and to which I have given consent to intercept my traffic, should be able to intercept the communications. The real world presents situations that are more nuanced than "encrypt everything and don't let anyone between me and the destination to see what is going on." There are many places where the above is the desired and sensible requirement. There are also many use cases where crypto is warranted, but select parties should have the ability to break it. How this should happen is to be seen. In the examples I have given above, "consent" will have to come both in the idea of consent, as well as some crypto key that will allow the privileged proxies to intercept my traffic.

pavs 9y ago
In some countries, there are "secret laws" (not the USA), where government body that controls ISP license and legalese issues can force ISPs to keep logs, not just metadata, of individual user browsing and share it with law enforcement official - whenever asked without any form of a court order and legal paper. We already have to share the 'User Form' the users sign up when getting internet connections, which has all kinds of personal information including pictures, address, phone number and national ID number. Failure to do so will get you heavily fined and get your license revoked to do business. Also, you can't talk about it to the public. I have friends and family in at least three countries who are involved in this industry and have confirmed me that this is a routine process, log sharing, port-mirroring, putting black-boxes in the middle of your core network is just routine work and has been the case for many years.
- djsumdog 9y ago
  I was going to guess one of these countries is China, but they don't really have secret laws; they monitoring everything out with mandates that are out in the open.
  - mafuy 9y ago
    The parent was probably referring to laws pertaining to secrets, not laws that themselves are secret.
- koliber 9y ago
  I think that in such situations where a citizen of said country is not granting the operator the right to snoop, TLS 1.3 and it's inability to snoop accomplish the goal perfectly. Perhaps such countries will outlaw TLS 1.3. Who knows. The US did outlaw strong encryption at one point because it didn't allow it access to data it wanted to have access to.
  - robin_reala 9y ago
    To your second point, that’s not exactly what happened. 128-bit encryption wasn’t outlawed, it was just illegal to export (the more useless 40-bit encryption was fine). There were various ways of working around this export ban before 2000 when it was rescinded (for most countries). https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States#PC_era https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...
fulafel 9y ago
There is a strong argument that in the financial-institution case you should be just blocking web-bound TLS traffic, instead of lobbying internet standards to break TLS. The applications that want to route their traffic through inspection proxies can then do so explicitly.
- koliber 9y ago
  One of the issues is that, due to poorly constructed legislation or private contracts, there is may be a requirement to provide "industry-standard" protection to various network connections. TLS 1.3 will, in due time, be the industry standard. This needs to be reconciled with the conflicting requirement to log, record, and or block connections based on content. Perhaps TLS 1.3 is not the solution here, as it can not reconcile this conflict. Perhaps something else needs to be developed that will provide a solution that meets these two requirements.
  - pas 9y ago
    Could you cite the exact statute that requires logging mere connections? I thought most of these compliance frameworks don't really specify how, just compile, archive and produce the data periodically (or on demand). And make the system tamper-proof (or tamper-evident), and get it audited from time to time.
    - wglb 9y ago
      I am not aware of legislation, but there are many industries where there are compliance requirements that require monitoring, for example financial institutions, possibly FISMA.
  - semi-extrinsic 9y ago
    Where I work, the company has a TLS 1.2 proxy as discussed in the article. The stated purpose is to intercept malware. It frequently fails, as the fine article states, and people then either use their personal phone and 4G to wifi, or proxy traffic over ssh to a server they have at home. I can't imagine it's anything but "something must be done, we're doing something." Furthermore, as most large companies install these, won't malware authors just start proxying C&C traffic over ssh on port 80? Or use other non-interceptable secure channels?
deleted 9y ago
[deleted]
rocqua 9y ago
Note that nothing about TLS 1.3 prevents a Proxy whose CA certificate is installed by the user from MitMing a TLS 1.3 session. This is also why certificate pins are ignored when a cert is signed by a manually installed certificate. What TLS 1.3 does appear to do is make it harder to optimize this proxying, and make it impossible to be selective about what you proxy. However, both such optimizations and selective proxying are apparently hard to implement securely. Now, selective proxying is nice to have. It is better if enterprises don't intercept traffic to banks or social networks. However, it seems to me like facebook would be a nice side-channel for exfiltrating data. It seems to me that selective proxying could still be solved at the DNS level. Make any domain except for the whitelisted ones resolve to a proxy, and the have the proxy in between all traffic. This means you also proxy all unencrypted traffic to the outside world, but if you are proxying TLS, you probably want to block or proxy plaintext outbound connections as well.
- mhils 9y ago
  > What TLS 1.3 does appear to do is make it harder to optimize this proxying, and make it impossible to be selective about what you proxy. You have the ServerNameIndication (SNI) in the ClientHello, so selective proxying is very easy to implement with TLS 1.3. SNI wasn't mandatory in older versions, which is why middleboxes went for this "let's inspect the certificate" dance in the first place.
  - rocqua 9y ago
    To do TLS proxying properly, you need to verify the cert on 'trusted' domains. SNI is not verified. Thus, a proxy using SNI to identify the host would be circumvented by using facebook.com or www.bankofamerica.com as the name in SNI and just ignoring SNI at the malicious endpoint. As TLS 1.3 encrypts the certificate, you can't check the certificate without actually MitMing the connection. Thus, whitelisting isn't possible in TLS 1.3. Unless you trust the (attacker controlled) SNI, at which point, why even do TLS proxying. Note that according to the article, many TLS 1.2 proxies don't actually verify the certificate by default, which means my masquerade as facebook.com ploy would also work against them. This can be done by simply using a false 'common name' field in the cert. The defense against this is easy, it is the certificate validation all browsers do. Apparently, these middle boxes by default do not use this validation. This is generally seen as a compelling argument against the deployment of TLS proxies. The argument being that they are 'security theater' as opposed to actual security, on account of them being easy to spoof.
wolfgke 9y ago
> The real world presents situations that are more nuanced than "encrypt everything and don't let anyone between me and the destination to see what is going on." There are many places where the above is the desired and sensible requirement. There are also many use cases where crypto is warranted, but select parties should have the ability to break it. In these institutions just block TLS 1.3 connections in the firewall. Where is the problem?
baby 9y ago
> This company, in order to adhere with record-keeping laws, needs to log all network connections. One of the conditions of my employment is that I authorize the company to intercept my network communications Does that mean they also need to intercept communications from your phone to the internet when you're at work?
- geofft 9y ago
  Generally no, because your phone is not allowed to have access to business records.
  - baby 9y ago
    what about the camera of your phone?
baby 9y ago
> Let's say I am employee of a financial institution So one institution has law requirements that break users' rights so we must change the internet for them
- rocqua 9y ago
  Just because someone sits behind a computer doesn't mean they get to have complete control over and privacy within that computer. Specifically, when they do not own that computer and are payed by someone else to do work using that computer. In this sense, corporate users truly are different from private users. Similarly, company e-mail is not confidential. A very important requirement to this treatment of corporate users is that the end user ought to be made aware of this. Both with the company e-mail and the proxied company computer. Part of the issue here is that sometimes encryption is bad. I for one dread the day I'll have to install some binary blob that communicates using TLS with a pinned cert I cannot override. Similarly, encryption and secure hardware modules are what enable boot-locked devices. The point being, cryptography can be used to take away control. Not just from big institutions but also from end users. If we admit that sometimes cryptography is bad, there might be cases where we want a controlled way to break it. Again, this should be done with notice and all responsibilities lying with those taking the risk. That is, the party responsible for securing the proxy is also the party that is screwed when the proxy is compromised. This might sound like encouraging key-escrow for government acces. It definitely does not. The issue there is notice (or choice, if non-escrow becomes outlawed) and the fact that a compromised system hurts end users, not the government. Thus, the incentives are misaligned for the government.
  - baby 9y ago
    > If we admit that sometimes cryptography is bad I'm not sure I follow, so because HSTS is a disaster then encryption is bad and we should switch to no encryption?
    - rocqua 9y ago
      No, the point is simply that sometimes encryption has bad results. The example being an application that talks to its home server over an encrypted connection which cannot be audited. Then, I propose we should also take issue with encryption that prevents TLS proxying in corporate settings.

pavs 9y ago

In some countries, there are "secret laws" (not the USA), where government body that controls ISP license and legalese issues can force ISPs to keep logs, not just metadata, of individual user browsing and share it with law enforcement official - whenever asked without any form of a court order and legal paper. We already have to share the 'User Form' the users sign up when getting internet connections, which has all kinds of personal information including pictures, address, phone number and national ID number. Failure to do so will get you heavily fined and get your license revoked to do business. Also, you can't talk about it to the public. I have friends and family in at least three countries who are involved in this industry and have confirmed me that this is a routine process, log sharing, port-mirroring, putting black-boxes in the middle of your core network is just routine work and has been the case for many years.

djsumdog 9y ago
I was going to guess one of these countries is China, but they don't really have secret laws; they monitoring everything out with mandates that are out in the open.
- mafuy 9y ago
  The parent was probably referring to laws pertaining to secrets, not laws that themselves are secret.
koliber 9y ago
I think that in such situations where a citizen of said country is not granting the operator the right to snoop, TLS 1.3 and it's inability to snoop accomplish the goal perfectly. Perhaps such countries will outlaw TLS 1.3. Who knows. The US did outlaw strong encryption at one point because it didn't allow it access to data it wanted to have access to.
- robin_reala 9y ago
  To your second point, that’s not exactly what happened. 128-bit encryption wasn’t outlawed, it was just illegal to export (the more useless 40-bit encryption was fine). There were various ways of working around this export ban before 2000 when it was rescinded (for most countries). https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States#PC_era https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...

fulafel 9y ago

There is a strong argument that in the financial-institution case you should be just blocking web-bound TLS traffic, instead of lobbying internet standards to break TLS. The applications that want to route their traffic through inspection proxies can then do so explicitly.

koliber 9y ago
One of the issues is that, due to poorly constructed legislation or private contracts, there is may be a requirement to provide "industry-standard" protection to various network connections. TLS 1.3 will, in due time, be the industry standard. This needs to be reconciled with the conflicting requirement to log, record, and or block connections based on content. Perhaps TLS 1.3 is not the solution here, as it can not reconcile this conflict. Perhaps something else needs to be developed that will provide a solution that meets these two requirements.
- pas 9y ago
  Could you cite the exact statute that requires logging mere connections? I thought most of these compliance frameworks don't really specify how, just compile, archive and produce the data periodically (or on demand). And make the system tamper-proof (or tamper-evident), and get it audited from time to time.
  - wglb 9y ago
    I am not aware of legislation, but there are many industries where there are compliance requirements that require monitoring, for example financial institutions, possibly FISMA.
- semi-extrinsic 9y ago
  Where I work, the company has a TLS 1.2 proxy as discussed in the article. The stated purpose is to intercept malware. It frequently fails, as the fine article states, and people then either use their personal phone and 4G to wifi, or proxy traffic over ssh to a server they have at home. I can't imagine it's anything but "something must be done, we're doing something." Furthermore, as most large companies install these, won't malware authors just start proxying C&C traffic over ssh on port 80? Or use other non-interceptable secure channels?

deleted 9y ago

[deleted]

rocqua 9y ago

Note that nothing about TLS 1.3 prevents a Proxy whose CA certificate is installed by the user from MitMing a TLS 1.3 session. This is also why certificate pins are ignored when a cert is signed by a manually installed certificate. What TLS 1.3 does appear to do is make it harder to optimize this proxying, and make it impossible to be selective about what you proxy. However, both such optimizations and selective proxying are apparently hard to implement securely. Now, selective proxying is nice to have. It is better if enterprises don't intercept traffic to banks or social networks. However, it seems to me like facebook would be a nice side-channel for exfiltrating data. It seems to me that selective proxying could still be solved at the DNS level. Make any domain except for the whitelisted ones resolve to a proxy, and the have the proxy in between all traffic. This means you also proxy all unencrypted traffic to the outside world, but if you are proxying TLS, you probably want to block or proxy plaintext outbound connections as well.

mhils 9y ago
> What TLS 1.3 does appear to do is make it harder to optimize this proxying, and make it impossible to be selective about what you proxy. You have the ServerNameIndication (SNI) in the ClientHello, so selective proxying is very easy to implement with TLS 1.3. SNI wasn't mandatory in older versions, which is why middleboxes went for this "let's inspect the certificate" dance in the first place.
- rocqua 9y ago
  To do TLS proxying properly, you need to verify the cert on 'trusted' domains. SNI is not verified. Thus, a proxy using SNI to identify the host would be circumvented by using facebook.com or www.bankofamerica.com as the name in SNI and just ignoring SNI at the malicious endpoint. As TLS 1.3 encrypts the certificate, you can't check the certificate without actually MitMing the connection. Thus, whitelisting isn't possible in TLS 1.3. Unless you trust the (attacker controlled) SNI, at which point, why even do TLS proxying. Note that according to the article, many TLS 1.2 proxies don't actually verify the certificate by default, which means my masquerade as facebook.com ploy would also work against them. This can be done by simply using a false 'common name' field in the cert. The defense against this is easy, it is the certificate validation all browsers do. Apparently, these middle boxes by default do not use this validation. This is generally seen as a compelling argument against the deployment of TLS proxies. The argument being that they are 'security theater' as opposed to actual security, on account of them being easy to spoof.

wolfgke 9y ago

> The real world presents situations that are more nuanced than "encrypt everything and don't let anyone between me and the destination to see what is going on." There are many places where the above is the desired and sensible requirement. There are also many use cases where crypto is warranted, but select parties should have the ability to break it. In these institutions just block TLS 1.3 connections in the firewall. Where is the problem?

baby 9y ago

> This company, in order to adhere with record-keeping laws, needs to log all network connections. One of the conditions of my employment is that I authorize the company to intercept my network communications Does that mean they also need to intercept communications from your phone to the internet when you're at work?

geofft 9y ago
Generally no, because your phone is not allowed to have access to business records.
- baby 9y ago
  what about the camera of your phone?

baby 9y ago

> Let's say I am employee of a financial institution So one institution has law requirements that break users' rights so we must change the internet for them

rocqua 9y ago
Just because someone sits behind a computer doesn't mean they get to have complete control over and privacy within that computer. Specifically, when they do not own that computer and are payed by someone else to do work using that computer. In this sense, corporate users truly are different from private users. Similarly, company e-mail is not confidential. A very important requirement to this treatment of corporate users is that the end user ought to be made aware of this. Both with the company e-mail and the proxied company computer. Part of the issue here is that sometimes encryption is bad. I for one dread the day I'll have to install some binary blob that communicates using TLS with a pinned cert I cannot override. Similarly, encryption and secure hardware modules are what enable boot-locked devices. The point being, cryptography can be used to take away control. Not just from big institutions but also from end users. If we admit that sometimes cryptography is bad, there might be cases where we want a controlled way to break it. Again, this should be done with notice and all responsibilities lying with those taking the risk. That is, the party responsible for securing the proxy is also the party that is screwed when the proxy is compromised. This might sound like encouraging key-escrow for government acces. It definitely does not. The issue there is notice (or choice, if non-escrow becomes outlawed) and the fact that a compromised system hurts end users, not the government. Thus, the incentives are misaligned for the government.
- baby 9y ago
  > If we admit that sometimes cryptography is bad I'm not sure I follow, so because HSTS is a disaster then encryption is bad and we should switch to no encryption?
  - rocqua 9y ago
    No, the point is simply that sometimes encryption has bad results. The example being an application that talks to its home server over an encrypted connection which cannot be audited. Then, I propose we should also take issue with encryption that prevents TLS proxying in corporate settings.