:fa_unlock: We might as well stop backing Apple, and Lojban encryption...


  • Discourse touched me in a no-no place

    If the proxy is done right, a CONNECT is done via the proxy and then you're talking to the back end, and you can actually verify that you are because you can establish the security identity of the other side correctly. The proxy is just proxying the encrypted packets, and can't see inside the connection.

    But lots of idiots panic over the thought that they might occasionally have to trust their employees.



  • That would be "right" from the employee's perspective, but the employer's perspective...?



  • Emmm... shouldn't the "employee" and "employer" in that sentence be reversed?

    Btw, IMO employee wouldn't want to be put under surveillance during their work unless in special cases that it's for their own safety.



  • Why hasn't anyone invented a version of TLS that encrypts and signs data separately so the data can be read by the MITM machine (with its identity verified somehow by the client, of course) and also be verified as coming from the correct server by the client?


  • Discourse touched me in a no-no place

    @ben_lubar said:

    Why hasn't anyone invented a version of TLS that encrypts and signs data separately so the data can be read by the MITM machine (with its identity verified somehow by the client, of course) and also be verified as coming from the correct server by the client?

    They have, and variations on the theme are options in some of the more advanced SOAP stacks, but it turns out that nobody really wants it. Straight end-to-end connection confidentiality is quite enough for the majority of scenarios.



  • @cheong said:

    Emmm... shouldn't the "employee" and "employer" in that sentence be reversed?

    No.

    @cheong said:

    employee wouldn't want to be put under surveillance during their work

    Correct.

    Employer, on the other hand, might have a different idea of how to do a proxy "right"... one that would involve monitoring everything going across their network and onto their work machines. You and I would call that "wrong".

    So I guess the real question is, can the employer do the proxy "wrong" so that they're monitoring all of the unencrypted data? Well, obviously they can, but can they do it in such a way that the employee can't tell?



  • @anotherusername said:

    but can they do it in such a way that the employee can't tell

    TLS says no.



  • If I recall correctly, a root certificate installed on the machines can allow the employer to silently see all of the decrypted traffic.

    ...granted, you could check the computer's certificates, but who actually does that, and would you actually notice it in the giant list?



  • You do recall correctly, which is why a) browsers other than IE and Safari tend not to use the OS' certificate store anymore, and b) browser security improvements under the HSTS umbrella include certificate pinning, where if a connection (or preload list) includes a notation that the public key will not change, the browser will reject a cert with a changed public key even if it would otherwise be valid, screaming like an angry toddler and refusing to generate traffic to decrypt.



  • @anotherusername said:

    @cheong said:
    Emmm... shouldn't the "employee" and "employer" in that sentence be reversed?

    No.

    Okay, so your "right" should be "correct". I think there is ambiguity on the meaning of "right" there: "correct" and / or "expediency".



  • I remember that Firefox has a plugin that'll notify you if the certificate changed between current and previous access. So after the certificate is checked in your first time access, you can assume the certificate is not tempered if warning is not shown there. (Unless they login your machine using your account at night to clear that data)

    Better yet, if all they give you is a notebook computer, or the motherboard comes with WiFi function, or in case it's USB port is not disable, use a WiFi dongle, try to use your mobile phone as hotspot to visit some site to see if that triggers a warning. If so, it's a sign that the certificate data of the plugin has been tinkered.

    Note that these might go against your company's I.T. policy and can get you fired if discovered. If you're not planning to change job, better check your company's policy before doing so.

    @TwelveBaud said:

    You do recall correctly, which is why a) browsers other than IE and Safari tend not to use the OS' certificate store anymore, and b) browser security improvements under the HSTS umbrella include certificate pinning, where if a connection (or preload list) includes a notation that the public key will not change, the browser will reject a cert with a changed public key even if it would otherwise be valid, screaming like an angry toddler and refusing to generate traffic to decrypt.

    Chrome also use system certificate store. And it's easy to inject a meddled CA store in default user location for Firefox.

    Note that when all traffics goes pass the proxy unencrypted, the proxy is free to add or remove any HTTP headers as they sees fit.

    If you really want to know whether you're put under surveillance, it could not be done without access to external network bypassing the company network.


  • :belt_onion:

    @cheong said:

    Chrome also use system certificate store.

    But if someone tries to MITM a Google site, Chrome complains very loudly IIRC



  • Humm... I use Chrome to visit Google with Fiddler HTTPS decryption (which will replace HTTPS certificate) enabled, and it doesn't complaint (the certificate information does show the Fiddler replacement certificate).

    And btw, since it seems Chrome wants to win the brower market for the business (they add GPO template to allow domain level management), I doubt they'll say anything since those computers are assets of the company regarding the MITM as long as the scope is "inside that company only".


  • :belt_onion:

    Interesting.

    According to https://www.chromium.org/Home/chromium-security/education/tls, most Google sites are cert pinned to only accept whitelisted certs. So... idk


  • :belt_onion:

    https://www.imperialviolet.org/2011/05/04/pinning.html says

    There are a number of cases where HTTPS connections are intercepted by using local, ephemeral certificates. These certificates are signed by a root certificate that has to be manually installed on the client. Corporate MITM proxies may do this, several anti-virus/parental control products do this and debugging tools like Fiddler can also do this. Since we cannot break in these situations, user installed root CAs are given the authority to override pins. We don't believe that there will be any incompatibility issues.

    So apparently that case would work too. TIL.


  • Java Dev

    I can see their reasoning on that, but I think an argument could be made for at least using a different URL bar icon in that case.


  • Discourse touched me in a no-no place

    @PleegWat said:

    I can see their reasoning on that, but I think an argument could be made for at least using a different URL bar icon in that case.

    An icon with a creepy guy in a suspicious-looking hat peering at the user? That would work. Especially when it comes up on the connections that the intrusive boss uses while communicating with his mistress financial “adviser”


Log in to reply