4 ms·

The problem I have with TLS 1.3 proposal is it’s gonna stop me having control over the things that go out of my own network :( Realise that this is a multiface

The problem I have with TLS 1.3 proposal is it’s gonna stop me having control over the things that go out of my own network :( Realise that this is a multifaceted debate but it’s going to destroy the utility of anything I can’t install a certificate on, and also force me to install certs on everything I own before I can comfortably let those things on the network. It’s gonna screw a lot of enterprise use cases as well. I’m not sure people fully get that the privacy extended to say “dissidents in Syria” is also going to apply to HP printers on their own networks trying to figure out whether to show “toner low” dialogs. Personally I don’t think the “hey the dissidents” value is worth it since those people are pretty screwed anyway - filtering at scale can still work out what you’re connecting to (ips, latency, response size patterns, blah blah) but it really messes up anyone (person or enterprise) who wants to use stuff but also know what’s going on.

pilif 8y ago
>also force me to install certs on everything I own before I can comfortably let those things on the network I'm curious: How is TLS 1.3 different from TLS 1.2 in that regard? How would you implement an intercepting proxy with TLS 1.2 and without installing a CA cert in the clients?
- ameshkov 8y ago
  I guess the encrypted SNI draft is what's meant here.
  - xyzzy123 8y ago
    Thanks, sorry, you are totally right and I should be more specific. Yes. It’s a metadata leak and generally I am pro the end-to-end principle but encrypted SNI actually forces everyone to MITM. Whether that is good or bad is a value judgement but for people who have been doing “light touch” egress filtering it is a huge PITA. It is actually going to force more invasive surveillance in basically any regulated workplace.
    - pilif 8y ago
      Personally, I think it's a good thing it forces MITM. Either you monitor your users browsing habits or you don't. If you do, it's only fair if they have a chance to know that you do and seeing an SSL connection be "protected" by a company-internal cert makes that totally clear.
      - amaccuish 8y ago
        The thing is, most users won't look for that. I like what Android does, where if you switch on a VPN or install an extra CA, you get a "your network use may be being monitored". That should appear in the browser.
    - icebraining 8y ago
      How could you rely on SNI for filtering? How did you know they weren't just domain fronting? Or was it about blocking access to regular sites?
      - deleted 8y ago
        [deleted]
tialaramex 8y ago
The threat you're worried about doesn't require that an IETF Working Group spend years defining a new protocol, whether that's QUIC or TLS 1.3 itself. Any bozo could roll their own Noise-based encrypted protocol and it wouldn't be decrypted by whatever edge "security" you think is protecting you. Worse, chances are that a belief you presently have "control over the things that go out of my own network" but believe TLS 1.3 would hurt that means you're relying on "Next Generation Firewall" type technologies which are hopelessly broken. If you go stare at the TLS 1.3 "compatibility" changes in later drafts (particularly Draft 28 IIRC) you'll see that it's basically the equivalent of wearing a boiler suit with an embroidered "OTIS Lifts" logo to get waved through the gate check without needing a pass. Except the boiler suit says "TLS 1.2 Session Resumption". It didn't require the IETF to do this, presumably Bad Guys have been doing it for years without writing a document explaining how. The recurring theme in people's TLS 1.3 horror stories is that they were being eaten by cannibals all along, but TLS 1.3 asked them why they can't feel their legs... Example: Palo Alto and Cisco both shipped products that trip the TLS 1.3 downgrade detection feature. They were told about this months ago, but of course they waited until the last moment (indeed for PAN they still haven't shipped a fix for some supported versions) because it's just a compatibility problem... Except, it's not - the only way to trip that downgrade detection "by mistake" is to not choose random numbers where the TLS 1.0, 1.1 and 1.2 standards all say that it's imperative to use random numbers. If those numbers are instead copied from somewhere predictable (which they are in affected Cisco and Palo Alto systems) then much of the security of your TLS connections through these "security" devices was illusory.
- deleted 8y ago
  [deleted]
ryukafalz 8y ago
As another commenter noted, you already don't have control over what leaves your network in that case. The new standards may make it more likely, but there's nothing stopping a device manufacturer from doing something similar now. Open a VPN tunnel back to the mothership and have fun analyzing that. The real problem here is that you can't trust the devices on your network. Devices should give the user control, not work against them, which sadly seems to be uncommon these days.
- jerf 8y ago
  Opening a VPN tunnel back to the mothership can be blocked. I can vouch that plenty of real security-conscious sites take steps that would prevent that for working for you. There are plenty of sites that seem to do a full whitelist-only connection list for their external network, with things in between checking the protocol internals to the extent they can too. You can push a VPN connection over any port, but honestly, given some of the scrutiny I've been put through for some of the network stuff I've put out, I still wouldn't care to guarantee that some high-security customer out there wouldn't notice that your "HTTP connection" is actually a VPN connection. By the time you're writing something deceptive enough to get through that, you're running the risk of some very nasty stories being run in the security press about your practices. It is not the case that everybody in the world just throws all their devices on to the network and then lets everything on it have unfettered outbound access.
  - ryukafalz 8y ago
    And of course it's fine to block connections you don't recognize, or to whitelist connections in the first place. But I maintain that within a network of devices you own, the solution to untrustworthy devices on your network is to use more trustworthy devices, not to weaken internet standards for everyone else.
    - forgottenpass 8y ago
      the solution to untrustworthy devices on your network is to use more trustworthy devices This kind of "oh, only buy perfect end devices" is just as worthless advice as "oh, only buy service from perfect ISPs that don't make you want to encrypt traffic."

pilif 8y ago

>also force me to install certs on everything I own before I can comfortably let those things on the network I'm curious: How is TLS 1.3 different from TLS 1.2 in that regard? How would you implement an intercepting proxy with TLS 1.2 and without installing a CA cert in the clients?

ameshkov 8y ago
I guess the encrypted SNI draft is what's meant here.
- xyzzy123 8y ago
  Thanks, sorry, you are totally right and I should be more specific. Yes. It’s a metadata leak and generally I am pro the end-to-end principle but encrypted SNI actually forces everyone to MITM. Whether that is good or bad is a value judgement but for people who have been doing “light touch” egress filtering it is a huge PITA. It is actually going to force more invasive surveillance in basically any regulated workplace.
  - pilif 8y ago
    Personally, I think it's a good thing it forces MITM. Either you monitor your users browsing habits or you don't. If you do, it's only fair if they have a chance to know that you do and seeing an SSL connection be "protected" by a company-internal cert makes that totally clear.
    - amaccuish 8y ago
      The thing is, most users won't look for that. I like what Android does, where if you switch on a VPN or install an extra CA, you get a "your network use may be being monitored". That should appear in the browser.
  - icebraining 8y ago
    How could you rely on SNI for filtering? How did you know they weren't just domain fronting? Or was it about blocking access to regular sites?
    - deleted 8y ago
      [deleted]

tialaramex 8y ago

The threat you're worried about doesn't require that an IETF Working Group spend years defining a new protocol, whether that's QUIC or TLS 1.3 itself. Any bozo could roll their own Noise-based encrypted protocol and it wouldn't be decrypted by whatever edge "security" you think is protecting you. Worse, chances are that a belief you presently have "control over the things that go out of my own network" but believe TLS 1.3 would hurt that means you're relying on "Next Generation Firewall" type technologies which are hopelessly broken. If you go stare at the TLS 1.3 "compatibility" changes in later drafts (particularly Draft 28 IIRC) you'll see that it's basically the equivalent of wearing a boiler suit with an embroidered "OTIS Lifts" logo to get waved through the gate check without needing a pass. Except the boiler suit says "TLS 1.2 Session Resumption". It didn't require the IETF to do this, presumably Bad Guys have been doing it for years without writing a document explaining how. The recurring theme in people's TLS 1.3 horror stories is that they were being eaten by cannibals all along, but TLS 1.3 asked them why they can't feel their legs... Example: Palo Alto and Cisco both shipped products that trip the TLS 1.3 downgrade detection feature. They were told about this months ago, but of course they waited until the last moment (indeed for PAN they still haven't shipped a fix for some supported versions) because it's just a compatibility problem... Except, it's not - the only way to trip that downgrade detection "by mistake" is to not choose random numbers where the TLS 1.0, 1.1 and 1.2 standards all say that it's imperative to use random numbers. If those numbers are instead copied from somewhere predictable (which they are in affected Cisco and Palo Alto systems) then much of the security of your TLS connections through these "security" devices was illusory.

deleted 8y ago
[deleted]

ryukafalz 8y ago

As another commenter noted, you already don't have control over what leaves your network in that case. The new standards may make it more likely, but there's nothing stopping a device manufacturer from doing something similar now. Open a VPN tunnel back to the mothership and have fun analyzing that. The real problem here is that you can't trust the devices on your network. Devices should give the user control, not work against them, which sadly seems to be uncommon these days.

jerf 8y ago
Opening a VPN tunnel back to the mothership can be blocked. I can vouch that plenty of real security-conscious sites take steps that would prevent that for working for you. There are plenty of sites that seem to do a full whitelist-only connection list for their external network, with things in between checking the protocol internals to the extent they can too. You can push a VPN connection over any port, but honestly, given some of the scrutiny I've been put through for some of the network stuff I've put out, I still wouldn't care to guarantee that some high-security customer out there wouldn't notice that your "HTTP connection" is actually a VPN connection. By the time you're writing something deceptive enough to get through that, you're running the risk of some very nasty stories being run in the security press about your practices. It is not the case that everybody in the world just throws all their devices on to the network and then lets everything on it have unfettered outbound access.
- ryukafalz 8y ago
  And of course it's fine to block connections you don't recognize, or to whitelist connections in the first place. But I maintain that within a network of devices you own, the solution to untrustworthy devices on your network is to use more trustworthy devices, not to weaken internet standards for everyone else.
  - forgottenpass 8y ago
    the solution to untrustworthy devices on your network is to use more trustworthy devices This kind of "oh, only buy perfect end devices" is just as worthless advice as "oh, only buy service from perfect ISPs that don't make you want to encrypt traffic."