15 ms·

TLS 1.3 and Proxies

304 points by wglb 9y ago

nimbius 9y ago
the reason TLS1.3 has been delayed so long is vendors and researchers that believe the dual-speek that TLS needs to be both secure, as well as readily interceptable (and therefore insecure) in order for it to be "ready" to use. TLS and encryption arent going anywhere and theyre not always going to wait around for a concensus from industry. The sobering truth is that if not now, than in a decade or so the companies shilling TLS/SSL interception appliances and software will need to shift focus as the protocol will likely have been evolved by force over time to meet the needs of increasingly prevalent surveillance states. TLS interception or "proxying" started out as a graduate students parlour trick and eventually evolved into an entire shady industry where players like Bluecoat are routinely caught selling their products and services to repressive regimes. Heres hoping LibreSSL delivers the goods with or without the marketing teams say.
- Buge 9y ago
  >the protocol will likely have been evolved by force over time to meet the needs of increasingly prevalent surveillance states. Are you saying the protocol will be easier or harder to intercept in the future?
- wmf 9y ago
  To be clear, TLS 1.3 has no (or negative) support for interception. The delays are due to adding hacks to cleanly prevent interception, not to add it.
- dictum 9y ago
  I agree with regards to appliances like Bluecoat, but is TLS as a black box to keep users from seeing what the device is sending over the wire better?
  - mhils 9y ago
    This needs to be highlighted more often. TLS interception can be a very effective tool to expose insecure APIs and blatant privacy violations. It's ultimately a tradeoff between security (no bad interception) and privacy (no idea what my device is sending).
    - Godel_unicode 9y ago
      I agree, I'm continually saddened by the zealotry of the anti-surveillance lobby and the seeming dismissal of the privacy focused hacker who wants to know when exactly does Uber send data, and what exactly do they send. Especially when it goes as far as encoding the philosophy that state actors are the only problem that matters into the very protocol.
      - wbl 9y ago
        TLS 1.3 still enables exactly that.
      - lox 9y ago
        Could you explain how TLS 1.3 in any way reduces your ability to intercept traffic on your own devices?
    - modeless 9y ago
      TLS doesn't prevent you from intercepting your end of the connection on a device you control. If you don't control your own device then the problem is with your device, not TLS. We shouldn't weaken TLS just because you chose to hand control of your device to someone else.
      - mhils 9y ago
        Well I agree. My main concern is that we're loosing that control in the name of security, in particular on mobile devices. Take Android as an example, which doesn't respect user-added CAs anymore for application traffic [1]. It's even worse with cert-pinned iOS apps where you cannot root easily, although Apple is at least trying to fix this with App Transport Security (which does respect user-added CAs). I definitely do not want to see a weaker TLS - 1.3 is great. At the same time, I do not want to have 'security improvements' that make it impossible for average developers to see their own device's traffic. That will ultimately enable insecure APIs and gross privacy violations behind TLS. [1] https://github.com/mitmproxy/mitmproxy/issues/2054 https://github.com/mitmproxy/mitmproxy/issues/2054
- geofft 9y ago
  I don't understand your reference to LibreSSL in the context of your comment—why would they be different from any of the other SSL implementations? Are they planning on implementing something else besides TLSv1.3 per spec, or intentionally implementing more or less than the spec requires?
- Spooky23 9y ago
  I should absolutely be able to intercept TLS traffic on my computers on my network. That's the distinction. Third party interception capability needs to be illegal and connections should be tamper evident. Frankly, I have a higher duty than user privacy. My users have access to data that's critically sensitive in various ways, in some cases they face criminal sanction. I need to both control and detect unauthorized software on the network and ensure that users are following the rules. More extreme privacy activists will make noises about things using endpoint based solutions or something similar. It's a bullshit position that will ultimately weaken security.
  - marcosdumay 9y ago
    On your computers, yes. On your network, not so much. You have no right to intercept data just because you are moving it from one side to the other. And that's the thing. There is nothing stopping those companies from analyzing the data once it reached a managed computer. It is just that they want the capacity to do that on computers they don't manage.
    - closeparen 9y ago
      TLS interception is predicated on whitelisting your own CA on the endpoint. Can't really do that if you don't manage it. And in any case, you need to be resilient to a rogue or compromised device.
    - Spooky23 9y ago
      Yeah, no. The network is my property and the contract our employees or partners sign establishes terms for using the network. You cannot get out of the network unless the traffic is proxied. There are a few exceptions for identify based reverse proxies that companies like Google talk about. But most places aren't there yet for sensitive applications outside of collaboration. There's also the matter of trust. Some business partners are explicitly trusted, either by a private CA signed certificate or by a specific third party key that is independently validated. Public networks are completely different. I am not talking about an ISP here.
darkhorn 9y ago
Some religious nuts are preventing me to visit Wikipedia. I use encrypted DNS to protect myself from man in middle attack, and it helps. But then they intercept certificate's name and drop the connection. So, thus this mean that TLS 1.3 will prevent sniffing certificate's name? And there won't be any certificate fingerprint on the wire to be sniffed, right?
- blattimwind 9y ago
  Active MITM remains able to sniff certificates, because the certificate is exchanged (indeed, must be exchanged) before you can authenticate the key exchange and thus lock out AMITM attackers.
  - vbezhenar 9y ago
    Is it possible to launch active MITM attack and then establish connection like it wasn't there? The point of sniffing certificate is to block access for some websites and allow for others, located on the same IP address. Otherwise you could just block IP.
- tialaramex 9y ago
  Under TLS 1.3 the Server Name Indication extension becomes mandatory, so your client will automatically, in plain text, transmit the full DNS name of whatever server it wants to talk to [SNI is there to make "virtual hosting" possible for HTTPS, which is why you can get working SSL on a cheap bulk host without paying them extra for a dedicated IP address] So, a middlebox might choose to drop connections based on the name your client sends (and of course it could also choose to drop them based on the destination IP address, the amount of traffic you've sent recently, or the phase of the moon). But the certificate itself is now always encrypted, so the middlebox can't snoop that without acting as a proxy. It sounds as though you've (perhaps against your will) accepted the proxy, so in that case all bets are off anyway, a proxy can do whatever it likes, if you don't want that don't trust proxies.
  - derefr 9y ago
    > Under TLS 1.3 the Server Name Indication extension becomes mandatory Is the client allowed to not send an SNI? If not, does this mean that HTTPS servers will no longer have a "default" HTTPS virtual host if accepting only TLSv1.3 connections? If you don't get to know anything about the backend at an IP until you've essentially proven you have a shared secret (the domain name), this could be a bad time for the folks who try to scan IP address space for HTTPS sites (e.g. the DDoSers who want to de-anonymize Cloudflare-protected backends in order to attack them directly.)
bb88 9y ago
Having worked in locked down networks before, I get the idea of securing resources and keeping secure data inside the network. But what bothers me, is I keep asking myself the question: When and why did we decide to give the proxy all the power in this relationship? If we have to use proxies, at least the proxy should be transparent about itself to all parties on the connection. Then my bank can drop the connection or restrict functions/data to non-proxied data, secure government servers can drop the connection, my browser can drop the connection and give me an error (because I don't want anyone snooping on my banking history), etc. Eg. Let's say I open the patient portal for my hospital through a proxy. Is the proxy software HIPAA compliant? What about the people that have access to my health data through the proxy software? In this case, I would think we should allow the portal software to drop the connection because the connection itself is not secure.
- cesarb 9y ago
  > In this case, I would think we should allow the portal software to drop the connection because the connection itself is not secure. It sounds like what you want is the server authenticating the client. That already exists in TLS: it's called a client certificate (complementing the usual server certificate, which authenticates the server to the client). Unless the MITM proxy has access to the client certificate's private key, or the server trusts the MITM proxy's CA, the proxy cannot impersonate the client.
  - sitepodmatt 9y ago
    Is any B2C mainstream bank using client certificates? I've not seen it in the wild. I think easier solution is just BYOD to work with 3g/4g SIM, you can pick up a reasonable 8" tablet for $100 that supplements your phone for when you need a bigger screen size.
    - cpach 9y ago
      ”Is any B2C mainstream bank using client certificates?” I doubt it. AFAIK the web browsers’ UI for handling client certificates is way too cumbersome for mainstream usage.
badrabbit 9y ago
Why not have the insecure or interceptable protocols as optional protocol extensions and make everyone happy? Much like with fips and how you can build openssl and other tls libs with fips mode on or off. TLS 1.3 client libraries could then optionally support interceptable key exchange depending on who is using them. An individual can use normal OS and distro that exclude the insecure features while banks and military facilities might turn it on. Alternatively,why the "one size fits all" approach? Why not have a "TLS-commercial". Obviously the "one size fits all" requires a comptomise by all parties resulting in a collective reduction of security.
- pdkl95 9y ago
  https://en.wikipedia.org/wiki/Downgrade_attack https://en.wikipedia.org/wiki/Downgrade_attack
- cesarb 9y ago
  > Why not have the insecure or interceptable protocols as optional protocol extensions and make everyone happy? That sounds like the "draft-rehired" proposal. Here's a list of arguments against it (and similar proposals): https://github.com/sftcd/tinfoil https://github.com/sftcd/tinfoil
koliber 9y ago
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.
fulafel 9y ago
Wow, the linked GCHQ piece is impressive: The title is that TLS 1.3 is "harder for enterprises" because "Many enterprises have security appliances that seek to look into TLS connections to make sure that the enterprise security is appropriately protected." And, later: "It certainly looks like it’ll have a negative effect on enterprise security." Open lobbying against crypto from the spooks, in the name of collective security, is of course not a new thing - but dressing it as necessary for "enterprise security" in standards lobbying is a clever move.
- robin_reala 9y ago
  To be fair to the original author, NCSC is no longer part of GCHQ.
  - fulafel 9y ago
    There is a prominent "a part of GCHQ" banner at the top.
    - robin_reala 9y ago
      Wow, that’s the biggest facepalm I’ve done recently. I was under the impression that they were officially split but apparently not. They’ve definitely now got seperate office blocks, and more of an operational split than the previous CESG ever had at least.
inlined 9y ago
Am I the only one noticing parallels between this debate and the debate over gun regulation in the US? Concerns that firearms or privacy are fundamental rights. Concerns that regulations on inspectability of destinations or restricted access of firearms are necessary others' safety Even the distrust of the government comes up in both debates. I have no actionable feedback from the parallels, just fascination.
newman314 9y ago
I'll reiterate what I said before. I'm for TLSv1.3 breaking middleboxes. It's more important to have good viable security rather than "my middleboxes". To me, it's like the FBI asking for NOBUS crypto.
- letsgetphysITal 9y ago
  The side effect of this is that corporate networks will become draconian in what services can be accessed from their networks. Expect everything outside of 10./8 to be black holed; No internet access of any kind. The company's legal requirement to prevent data exfiltration trumps your ability browse reddit during your lunch break. Plus, if they can't monitor the connection, they will monitor the endpoint.
  - woolvalley 9y ago
    Most places already monitor the endpoint already.
  - jessaustin 9y ago
    If only everyone with a job and most people without one had some kind of personal network device, compact enough to be kept in a pocket or purse yet powerful enough to "browse reddit"... Lots of corporate networks probably should be locked down to that extent. If they can't set up their own CA they're probably not doing a great job protecting their customers' private information.
  - tialaramex 9y ago
    The reality is that corporations always exist under a tension between an inclination to forbid everything, for fear it will cost the company money or reputation, and a need to allow everything so that people can get their jobs done or are willing to work there. The Internet is nothing special in this respect, large companies struggle to make policies that cover all the bases without strangling themselves and they will err on both sides of the line, sometimes learning from their mistakes and sometimes not so much.
  - fulafel 9y ago
peterwwillis 9y ago
I remember when TLS was about security, not privacy. I also remember when proxies were a tool to help everyone, not just corporations who wanted to inspect all your traffic. By ensuring that HTTPS is used everywhere, and that no other security regimes are allowed, they've killed proxies for all uses except spying on users. The end result is some of the Internet is now less private, by design. If you think proxies are a useful tool to save bandwidth, decrease latency and reduce load, and want to stay secure, but not necessarily private, there are very obvious ways this can be done. But there are people literally fighting against this because they want privacy or nothing. This is Internet puritanism.
- phicoh 9y ago
  Explicit proxies are no problem. There are a lot of servers behind proxies. No problem there. There is plenty of client software that can be configured to use proxies. Also no problem there. Where it goes wrong is transparent proxies (also called 'middleboxes') that operate without consent of the endpoints. In general, those proxies have caused so many network problems that most people involved in the IETF will happily see them die. And the easiest way to do that is to encrypt all traffic.
  - peterwwillis 9y ago
    There's a large number of web users - like myself - who benefited from transparent proxies. The IETF's complaints are probably almost certainly due to incompatibilities between products and erroneous modification of streams in transit, which of course should not happen. But it certainly doesn't need to die - if we killed technology for that, the whole WWW wouldn't exist.
andrewaylett 9y ago
A regular (non-transparent) HTTP proxy like Squid will process HTTP requests internally, but clients use CONNECT to forward their raw connection to the remote site for HTTPS. This is good: it means the client establishes a TLS connection with the origin. It would be really helpful, though, if there were an operating mode wherein one could instruct the proxy to talk to an HTTPS server without using CONNECT. So the browser talks to the proxy over TLS, and displays the proxy's certificate details, possibly with a big red warning, and the proxy terminates that TLS connection, decides what to do based on the request, makes a new onwards connection and gets the response plaintext too. The user obviously loses some privacy guarantees here, but no more than with an intercepting "transparent" proxy, and it's much clearer what's actually happening and which devices the user needs to trust. I'm much happier with an explicit proxy than any attempts at a transparent proxy that I've encountered, not least because it makes it possible for the browser to be clear to the user about what's happening.
bogomipz 9y ago
The author states: "The heuristics are necessarily imprecise because TLS extensions can change anything about a connection after the ClientHello and some additions to TLS have memorably broken them, leading to confused proxies cutting enterprises off from the internet." Can someone elaborate on a specific instance of this where a TLS extension lead to breakage? I don't doubt the author, quite the opposite - I'm interested in reading more about the specifics of it.
yuhong 9y ago
I have disliked the arms race against middleboxes since the beginning.
gheeh 9y ago
esdjfueudpogiejodipgjerdpjaedpdgjodjgkepodfkoskldfgkwlrf[pigrwodokerodikmawrodgkerdoijear0dpoijearokeardfo;eradjrnidugjarem'dgjawrdokwoajredgjwdihejdfgoaejxcpoifguajesdoajred0aoedgoielrjdgperajdgerjdporeforjeglejdgajzgowjgeirdfaerdpofmaerodgjearpidgkjaetd9fpgje9dpfjraepjraedofijes[olaetdojerp'fhmae'oidfjmhaoeisd;kersoaeirsdfjm'earidfkgaeridflkjgerdigjaers[0dijpoesjd0pgourajdpgourejdooerd0fieskdfjerdfgjre0o3jdojed[oljkdsijaekjedfspjhefspjaedf'aemsfjkaefsjaerdfgpjermdihjaedfjeadfijerdfgjadsxjaedgjaedsfoejsdfoedfpokeardpoaemrdpjhedojhepdfhjaeidfueardfiugoadfisgeroidfjgpresdfjaerpdfjprdfkherpidf
gheeh 9y ago
skdmopiredowelkfoewdkewpodskewpsdkgweijdgeropdfigmerdmgeoridjfgorepkdfrekfmoireklajdiowndgirekfdcmkljerkdjewspogwkgradogermdpgrdijdogwz0wrkarodgamerdp'jedfbkemadfreaidkjgwrpjrdmeaosxkmsoie'dfmeaujedikmo3aeuiaerdmjd[iedaoejdpeusdkgouog3auogaedeodsjrem'oieldgmei'ajdmgar'ikdgoaidjmeapdfkmear[dpgrdfkeisdfjkkt fm-smtfgmojkfm5qesfsjoiesmwrsjdfrsjdfg]e0soelsdjgesdfgepsdfkersdjfe 0rsdfae9sodfjesdfkesdfjh0eaudjerid

304 points by wglb 9y ago

the reason TLS1.3 has been delayed so long is vendors and researchers that believe the dual-speek that TLS needs to be both secure, as well as readily interceptable (and therefore insecure) in order for it to be "ready" to use. TLS and encryption arent going anywhere and theyre not always going to wait around for a concensus from industry. The sobering truth is that if not now, than in a decade or so the companies shilling TLS/SSL interception appliances and software will need to shift focus as the protocol will likely have been evolved by force over time to meet the needs of increasingly prevalent surveillance states. TLS interception or "proxying" started out as a graduate students parlour trick and eventually evolved into an entire shady industry where players like Bluecoat are routinely caught selling their products and services to repressive regimes. Heres hoping LibreSSL delivers the goods with or without the marketing teams say.

Buge 9y ago
>the protocol will likely have been evolved by force over time to meet the needs of increasingly prevalent surveillance states. Are you saying the protocol will be easier or harder to intercept in the future?
wmf 9y ago
To be clear, TLS 1.3 has no (or negative) support for interception. The delays are due to adding hacks to cleanly prevent interception, not to add it.
dictum 9y ago
I agree with regards to appliances like Bluecoat, but is TLS as a black box to keep users from seeing what the device is sending over the wire better?
- mhils 9y ago
  This needs to be highlighted more often. TLS interception can be a very effective tool to expose insecure APIs and blatant privacy violations. It's ultimately a tradeoff between security (no bad interception) and privacy (no idea what my device is sending).
  - Godel_unicode 9y ago
    I agree, I'm continually saddened by the zealotry of the anti-surveillance lobby and the seeming dismissal of the privacy focused hacker who wants to know when exactly does Uber send data, and what exactly do they send. Especially when it goes as far as encoding the philosophy that state actors are the only problem that matters into the very protocol.
    - wbl 9y ago
      TLS 1.3 still enables exactly that.
    - lox 9y ago
      Could you explain how TLS 1.3 in any way reduces your ability to intercept traffic on your own devices?
  - modeless 9y ago
    TLS doesn't prevent you from intercepting your end of the connection on a device you control. If you don't control your own device then the problem is with your device, not TLS. We shouldn't weaken TLS just because you chose to hand control of your device to someone else.
    - mhils 9y ago
      Well I agree. My main concern is that we're loosing that control in the name of security, in particular on mobile devices. Take Android as an example, which doesn't respect user-added CAs anymore for application traffic [1]. It's even worse with cert-pinned iOS apps where you cannot root easily, although Apple is at least trying to fix this with App Transport Security (which does respect user-added CAs). I definitely do not want to see a weaker TLS - 1.3 is great. At the same time, I do not want to have 'security improvements' that make it impossible for average developers to see their own device's traffic. That will ultimately enable insecure APIs and gross privacy violations behind TLS. [1] https://github.com/mitmproxy/mitmproxy/issues/2054 https://github.com/mitmproxy/mitmproxy/issues/2054
geofft 9y ago
I don't understand your reference to LibreSSL in the context of your comment—why would they be different from any of the other SSL implementations? Are they planning on implementing something else besides TLSv1.3 per spec, or intentionally implementing more or less than the spec requires?
Spooky23 9y ago
I should absolutely be able to intercept TLS traffic on my computers on my network. That's the distinction. Third party interception capability needs to be illegal and connections should be tamper evident. Frankly, I have a higher duty than user privacy. My users have access to data that's critically sensitive in various ways, in some cases they face criminal sanction. I need to both control and detect unauthorized software on the network and ensure that users are following the rules. More extreme privacy activists will make noises about things using endpoint based solutions or something similar. It's a bullshit position that will ultimately weaken security.
- marcosdumay 9y ago
  On your computers, yes. On your network, not so much. You have no right to intercept data just because you are moving it from one side to the other. And that's the thing. There is nothing stopping those companies from analyzing the data once it reached a managed computer. It is just that they want the capacity to do that on computers they don't manage.
  - closeparen 9y ago
    TLS interception is predicated on whitelisting your own CA on the endpoint. Can't really do that if you don't manage it. And in any case, you need to be resilient to a rogue or compromised device.
  - Spooky23 9y ago
    Yeah, no. The network is my property and the contract our employees or partners sign establishes terms for using the network. You cannot get out of the network unless the traffic is proxied. There are a few exceptions for identify based reverse proxies that companies like Google talk about. But most places aren't there yet for sensitive applications outside of collaboration. There's also the matter of trust. Some business partners are explicitly trusted, either by a private CA signed certificate or by a specific third party key that is independently validated. Public networks are completely different. I am not talking about an ISP here.

darkhorn 9y ago

Some religious nuts are preventing me to visit Wikipedia. I use encrypted DNS to protect myself from man in middle attack, and it helps. But then they intercept certificate's name and drop the connection. So, thus this mean that TLS 1.3 will prevent sniffing certificate's name? And there won't be any certificate fingerprint on the wire to be sniffed, right?

blattimwind 9y ago
Active MITM remains able to sniff certificates, because the certificate is exchanged (indeed, must be exchanged) before you can authenticate the key exchange and thus lock out AMITM attackers.
- vbezhenar 9y ago
  Is it possible to launch active MITM attack and then establish connection like it wasn't there? The point of sniffing certificate is to block access for some websites and allow for others, located on the same IP address. Otherwise you could just block IP.
tialaramex 9y ago
Under TLS 1.3 the Server Name Indication extension becomes mandatory, so your client will automatically, in plain text, transmit the full DNS name of whatever server it wants to talk to [SNI is there to make "virtual hosting" possible for HTTPS, which is why you can get working SSL on a cheap bulk host without paying them extra for a dedicated IP address] So, a middlebox might choose to drop connections based on the name your client sends (and of course it could also choose to drop them based on the destination IP address, the amount of traffic you've sent recently, or the phase of the moon). But the certificate itself is now always encrypted, so the middlebox can't snoop that without acting as a proxy. It sounds as though you've (perhaps against your will) accepted the proxy, so in that case all bets are off anyway, a proxy can do whatever it likes, if you don't want that don't trust proxies.
- derefr 9y ago
  > Under TLS 1.3 the Server Name Indication extension becomes mandatory Is the client allowed to not send an SNI? If not, does this mean that HTTPS servers will no longer have a "default" HTTPS virtual host if accepting only TLSv1.3 connections? If you don't get to know anything about the backend at an IP until you've essentially proven you have a shared secret (the domain name), this could be a bad time for the folks who try to scan IP address space for HTTPS sites (e.g. the DDoSers who want to de-anonymize Cloudflare-protected backends in order to attack them directly.)

bb88 9y ago

Having worked in locked down networks before, I get the idea of securing resources and keeping secure data inside the network. But what bothers me, is I keep asking myself the question: When and why did we decide to give the proxy all the power in this relationship? If we have to use proxies, at least the proxy should be transparent about itself to all parties on the connection. Then my bank can drop the connection or restrict functions/data to non-proxied data, secure government servers can drop the connection, my browser can drop the connection and give me an error (because I don't want anyone snooping on my banking history), etc. Eg. Let's say I open the patient portal for my hospital through a proxy. Is the proxy software HIPAA compliant? What about the people that have access to my health data through the proxy software? In this case, I would think we should allow the portal software to drop the connection because the connection itself is not secure.

cesarb 9y ago
> In this case, I would think we should allow the portal software to drop the connection because the connection itself is not secure. It sounds like what you want is the server authenticating the client. That already exists in TLS: it's called a client certificate (complementing the usual server certificate, which authenticates the server to the client). Unless the MITM proxy has access to the client certificate's private key, or the server trusts the MITM proxy's CA, the proxy cannot impersonate the client.
- sitepodmatt 9y ago
  Is any B2C mainstream bank using client certificates? I've not seen it in the wild. I think easier solution is just BYOD to work with 3g/4g SIM, you can pick up a reasonable 8" tablet for $100 that supplements your phone for when you need a bigger screen size.
  - cpach 9y ago
    ”Is any B2C mainstream bank using client certificates?” I doubt it. AFAIK the web browsers’ UI for handling client certificates is way too cumbersome for mainstream usage.

badrabbit 9y ago

Why not have the insecure or interceptable protocols as optional protocol extensions and make everyone happy? Much like with fips and how you can build openssl and other tls libs with fips mode on or off. TLS 1.3 client libraries could then optionally support interceptable key exchange depending on who is using them. An individual can use normal OS and distro that exclude the insecure features while banks and military facilities might turn it on. Alternatively,why the "one size fits all" approach? Why not have a "TLS-commercial". Obviously the "one size fits all" requires a comptomise by all parties resulting in a collective reduction of security.

pdkl95 9y ago
https://en.wikipedia.org/wiki/Downgrade_attack https://en.wikipedia.org/wiki/Downgrade_attack
cesarb 9y ago
> Why not have the insecure or interceptable protocols as optional protocol extensions and make everyone happy? That sounds like the "draft-rehired" proposal. Here's a list of arguments against it (and similar proposals): https://github.com/sftcd/tinfoil https://github.com/sftcd/tinfoil

koliber 9y ago

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.

fulafel 9y ago

Wow, the linked GCHQ piece is impressive: The title is that TLS 1.3 is "harder for enterprises" because "Many enterprises have security appliances that seek to look into TLS connections to make sure that the enterprise security is appropriately protected." And, later: "It certainly looks like it’ll have a negative effect on enterprise security." Open lobbying against crypto from the spooks, in the name of collective security, is of course not a new thing - but dressing it as necessary for "enterprise security" in standards lobbying is a clever move.

robin_reala 9y ago
To be fair to the original author, NCSC is no longer part of GCHQ.
- fulafel 9y ago
  There is a prominent "a part of GCHQ" banner at the top.
  - robin_reala 9y ago
    Wow, that’s the biggest facepalm I’ve done recently. I was under the impression that they were officially split but apparently not. They’ve definitely now got seperate office blocks, and more of an operational split than the previous CESG ever had at least.

inlined 9y ago

Am I the only one noticing parallels between this debate and the debate over gun regulation in the US? Concerns that firearms or privacy are fundamental rights. Concerns that regulations on inspectability of destinations or restricted access of firearms are necessary others' safety Even the distrust of the government comes up in both debates. I have no actionable feedback from the parallels, just fascination.

newman314 9y ago

I'll reiterate what I said before. I'm for TLSv1.3 breaking middleboxes. It's more important to have good viable security rather than "my middleboxes". To me, it's like the FBI asking for NOBUS crypto.

letsgetphysITal 9y ago
The side effect of this is that corporate networks will become draconian in what services can be accessed from their networks. Expect everything outside of 10./8 to be black holed; No internet access of any kind. The company's legal requirement to prevent data exfiltration trumps your ability browse reddit during your lunch break. Plus, if they can't monitor the connection, they will monitor the endpoint.
- woolvalley 9y ago
  Most places already monitor the endpoint already.
- jessaustin 9y ago
  If only everyone with a job and most people without one had some kind of personal network device, compact enough to be kept in a pocket or purse yet powerful enough to "browse reddit"... Lots of corporate networks probably should be locked down to that extent. If they can't set up their own CA they're probably not doing a great job protecting their customers' private information.
- tialaramex 9y ago
  The reality is that corporations always exist under a tension between an inclination to forbid everything, for fear it will cost the company money or reputation, and a need to allow everything so that people can get their jobs done or are willing to work there. The Internet is nothing special in this respect, large companies struggle to make policies that cover all the bases without strangling themselves and they will err on both sides of the line, sometimes learning from their mistakes and sometimes not so much.
- fulafel 9y ago

peterwwillis 9y ago

I remember when TLS was about security, not privacy. I also remember when proxies were a tool to help everyone, not just corporations who wanted to inspect all your traffic. By ensuring that HTTPS is used everywhere, and that no other security regimes are allowed, they've killed proxies for all uses except spying on users. The end result is some of the Internet is now less private, by design. If you think proxies are a useful tool to save bandwidth, decrease latency and reduce load, and want to stay secure, but not necessarily private, there are very obvious ways this can be done. But there are people literally fighting against this because they want privacy or nothing. This is Internet puritanism.

phicoh 9y ago
Explicit proxies are no problem. There are a lot of servers behind proxies. No problem there. There is plenty of client software that can be configured to use proxies. Also no problem there. Where it goes wrong is transparent proxies (also called 'middleboxes') that operate without consent of the endpoints. In general, those proxies have caused so many network problems that most people involved in the IETF will happily see them die. And the easiest way to do that is to encrypt all traffic.
- peterwwillis 9y ago
  There's a large number of web users - like myself - who benefited from transparent proxies. The IETF's complaints are probably almost certainly due to incompatibilities between products and erroneous modification of streams in transit, which of course should not happen. But it certainly doesn't need to die - if we killed technology for that, the whole WWW wouldn't exist.

andrewaylett 9y ago

A regular (non-transparent) HTTP proxy like Squid will process HTTP requests internally, but clients use CONNECT to forward their raw connection to the remote site for HTTPS. This is good: it means the client establishes a TLS connection with the origin. It would be really helpful, though, if there were an operating mode wherein one could instruct the proxy to talk to an HTTPS server without using CONNECT. So the browser talks to the proxy over TLS, and displays the proxy's certificate details, possibly with a big red warning, and the proxy terminates that TLS connection, decides what to do based on the request, makes a new onwards connection and gets the response plaintext too. The user obviously loses some privacy guarantees here, but no more than with an intercepting "transparent" proxy, and it's much clearer what's actually happening and which devices the user needs to trust. I'm much happier with an explicit proxy than any attempts at a transparent proxy that I've encountered, not least because it makes it possible for the browser to be clear to the user about what's happening.

bogomipz 9y ago

The author states: "The heuristics are necessarily imprecise because TLS extensions can change anything about a connection after the ClientHello and some additions to TLS have memorably broken them, leading to confused proxies cutting enterprises off from the internet." Can someone elaborate on a specific instance of this where a TLS extension lead to breakage? I don't doubt the author, quite the opposite - I'm interested in reading more about the specifics of it.

yuhong 9y ago

I have disliked the arms race against middleboxes since the beginning.

gheeh 9y ago

esdjfueudpogiejodipgjerdpjaedpdgjodjgkepodfkoskldfgkwlrf[pigrwodokerodikmawrodgkerdoijear0dpoijearokeardfo;eradjrnidugjarem'dgjawrdokwoajredgjwdihejdfgoaejxcpoifguajesdoajred0aoedgoielrjdgperajdgerjdporeforjeglejdgajzgowjgeirdfaerdpofmaerodgjearpidgkjaetd9fpgje9dpfjraepjraedofijes[olaetdojerp'fhmae'oidfjmhaoeisd;kersoaeirsdfjm'earidfkgaeridflkjgerdigjaers[0dijpoesjd0pgourajdpgourejdooerd0fieskdfjerdfgjre0o3jdojed[oljkdsijaekjedfspjhefspjaedf'aemsfjkaefsjaerdfgpjermdihjaedfjeadfijerdfgjadsxjaedgjaedsfoejsdfoedfpokeardpoaemrdpjhedojhepdfhjaeidfueardfiugoadfisgeroidfjgpresdfjaerpdfjprdfkherpidf

gheeh 9y ago

skdmopiredowelkfoewdkewpodskewpsdkgweijdgeropdfigmerdmgeoridjfgorepkdfrekfmoireklajdiowndgirekfdcmkljerkdjewspogwkgradogermdpgrdijdogwz0wrkarodgamerdp'jedfbkemadfreaidkjgwrpjrdmeaosxkmsoie'dfmeaujedikmo3aeuiaerdmjd[iedaoejdpeusdkgouog3auogaedeodsjrem'oieldgmei'ajdmgar'ikdgoaidjmeapdfkmear[dpgrdfkeisdfjkkt fm-smtfgmojkfm5qesfsjoiesmwrsjdfrsjdfg]e0soelsdjgesdfgepsdfkersdjfe 0rsdfae9sodfjesdfkesdfjh0eaudjerid