28 ms·

BlueCoat and other proxies hang up during TLS 1.3

288 points by coderobe 10y ago

JoshTriplett 10y ago
Note that this happens even when using a BlueCoat proxy in non-MITM mode. BlueCoat tries to "analyze" TLS connections, and rejects anything it doesn't understand. This exact issue occurred with TLS 1.2 back when BlueCoat only understood 1.1/1.0. In this case, it doesn't sound like they're reverting it because of overall breakage, but rather because it breaks the tool that would otherwise be used to control TLS 1.3 trials and other configuration. Firefox had a similar issue, where they temporarily used more conservative settings for their updater than for the browser itself, to ensure that people could always obtain updates that might improve the situation.
- coderobe 10y ago
  Rejecting anything it doesn't understand sounds like a bug to me. If it sees that it's TLS, it should attempt a protocol downgrade. There's absolutely no reason for this to break, as TLS 1.3 exists alongside TLS 1.2 (For now).
  - ehsankia 10y ago
    The surprising part (or maybe not) is that BlueCoat had been made aware of this change months ago and never got around properly testing it. This one of the softwares main purpose, and the fact that they didn't even make sure it works on the newest Chrome, leading to such a mess, is pretty sad.
    - deleted 10y ago
      [deleted]
    - nikanj 10y ago
      The way this is going to be spinned, I promise you, is: Google released a new version of Chrome, and support for that upgrade is in BlueCoat v.next. Here's an invoice for the new license+consulting services for the upgrade. In corporate environments, the last thing that changes is the thing that gets blamed. BlueCoat was not upgraded, Chrome was, and now things are broken? Not their fault.
  - 234dd57d2c8dba 10y ago
    It's a security feature, often malware will send encrypted traffic over 443 in an attempt to bypass firewalls. If BlueCoat can't understand the traffic, it drops it as it assumes it's malicious.
    - theamk 10y ago
      But the traffic is totally understandable -- the right action does not require knowing what TLS 1.3 is. The way it is supposed to work is as following: there is a protocol negotiation when the connection is established (which is obviously unencrypted), which contains TLS version supported. If MITM proxy does not understand the version, it can just change these bytes to force hosts to negotiate at a lower version. So the only reason BlueCoat fails is because the authors failed to implement force version downgrade.
    - jarym 10y ago
      The Bluecoat sales people did a number on you huh? Sounds really good until you ask 'why doesn't Bluecoat understand this traffic' - because it really should.
      - icebraining 10y ago
        TLS 1.3 is still quite new, doesn't seem outrageous that they take a bit to implement it.
        deathanatos 10y ago
        This is a failure to implement any version of TLS correctly, not just v1.3. (TLS has support for version negotiation including receiving a hello from a client with a future version, such as v1.3.)
  - userbinator 10y ago
    Rejecting anything it doesn't understand sounds like a bug to me. It sounds like a perfectly reasonable behaviour if the goal is to "fail closed", to provide more security in a fashion similar to a whitelist. If it sees that it's TLS, it should attempt a protocol downgrade. I don't remember the exact details but I recall reading that TLS has a mechanism to prevent version downgrades, precisely to defend against such "attacks", so the connection would not succeed in that case either.
    - coderobe 10y ago
      Client and Server exchange a list of capabilities at the beginning of a TLS connection, if the proxy just filters out the protocols/versions it doesn't understand, server/client will agree on a different version (like 1.2).
    - ademarre 10y ago
      > It sounds like a perfectly reasonable behaviour if the goal is to "fail closed", to provide more security in a fashion similar to a whitelist. This reminds me of firewalls that weaken security by filtering unrecognized HTTP headers: https://news.ycombinator.com/item?id=12655180 https://news.ycombinator.com/item?id=12655180
    - tbrowbdidnso 10y ago
      The TLS negotiation is mutual. Both endpoints tell each other what they support and they agree on a protocol that's mutually supported. If merely advertising 1.3 while still advertising older versions causes blue coat to break, it has a bug in TLS version negotiation. There is no downgrade or whitelist or failing closed. Each end says what they support and BlueCoat blows up the connection if it sees that the other end supports a newer version. It should say "oh we both support 1.2 let's use that" And apparently it's done this before so there's even less an excuse for it.
      - rocqua 10y ago
        This is apparently a problem when bluecoat is used in non-mitm mode. That probably means bluecoat is merely inspecting the initial handshake, not modifying it. That would imply it can't actually modify the handshake. It then simply inspects a connection it doesn't understand and 'fails closed' by preventing that connection.
  - jlgaddis 10y ago
    On the other hand, allowing stuff that you don't understand gives us things like the CSRF vulnerabilities in MongoDB and such. In the case of a security appliance -- such as this -- it should, in my opinion, "fail closed".
    - deathanatos 10y ago
      Sorry, no. TLS is explicitly designed to allow smooth upgrading like this. This proxy is supposed to (in response to a client hello w/ TLSv1.3) respond with TLSv1.2 if that's what it supports. This is still a rigorous parsing of the input being given: nothing is "not understood": version negotiation is an inherent part of the protocol and is supposed to allow for painless upgrades to more secure protocols. The RFC (which if you're implementing TLS, you should have open at all times) explicitly calls out exactly this behavior: > Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. The quality of this vendor's implementation is extremely suspect.
      - rocqua 10y ago
        The issue only occurs in non-mitm mode, probably meaning the box doesn't actually do the TLS handsake, instead merely inspecting it.
  - skywhopper 10y ago
    It's in BlueCoat's political interests to make sure TLS 1.3 rolls out as slowly as possible since it actively works against their entire business model, so they have zero incentive to be proactive about this until the TLS 1.3 extensions are approved that make MITM possible again.
- quotemstr 10y ago
  Ridiculously conservative middleboxes are why we can't have nice things and why we need to encrypt all new protocols, security properties aside.
  - jlgaddis 10y ago
    [ off-topic comment deleted ]
    - kbart 10y ago
      Probably you have already (mis)clicked (down)vote button on this comment before. It's easy to do accidentally, especially on touchscreen.
      - jlgaddis 10y ago
        I was pretty sure that wasn't it. I noticed it as soon as I first saw the comment. That's the simplest explanation, though, so that's probably what happened. Oh well.
  - DanielDent 10y ago
    This is precisely the conclusion Google reached and has used as they work on QUIC. Even protocol state (equivalents of TCP FIN/SYN/etc) is encrypted, to ensure that middleboxes don't get ideas about what the protocol is 'supposed' to do - ideas which make it hard to change the protocol in the future.
    - CapacitorSet 10y ago
      It is really sad that one reason why QUIC encrypts protocol states is to prevent excessively eager middleboxes from meddling with the traffic.
  - peterwwillis 10y ago
    Actually, no, that would just make everything more difficult. Browsers need to start coming to terms with the fact that they do not get do dictate how www networking operates for every organization around the world. There are hundreds of thousands of organizations that need inspection and caching and proxying of internal www traffic. That all protocols should disallow or frustrate this disregards real needs of users and organizations. Further still, if protocols can't be designed to be implemented easily or to allow for implementation bugs or lack of features, it's a crap protocol or application. Middleware will always be necessary, and encryption really shouldn't change the requirements of how middleware needs to work with a protocol.
- mrmondo 10y ago
  BlueCoat are an incredibly evil company that are breaking the internet.
  - rossy 10y ago
    BlueCoat makes me cry. We have an application running inside the firewall of one of our clients that communicates with a HTTPS REST API hosted by a server in our datacenter. The connection must be encrypted because it handles confidential information, but when it passes through BlueCoat's TLS proxy, the Authorization header gets mangled and it can't authenticate against our backend. Higher-ups decided that it would be better to try to convince the client to let our app bypass their proxy than to implement a custom workaround for BlueCoat users, but the client never let us through, so the only solution we could implement involved manually SCPing the required data between client and server.
    - reacweb 10y ago
      Ssh is almost often available to connect through the firewall. Do IT people understand how easily you can work around proxy using ssh ? Just start a vm in the cloud (like a C1 at scaleway for 3.6€ per month), install squid (with default options). On your PC, run portable applications: putty connected to your vm with a forward of proxy port and portable firefox configured to use your forwarded proxy.
      - jeroenhd 10y ago
        There's not even a need for installing a proxy! SSH has native SOCKS proxy support, so all you need to do is set up an SSH connection and set the browser connection to a dynamic SSH port forward. This also prevents leaking DNS requests : with a standard proxy your computer might be trying to look up domains using the company DNS system. With a SOCKS proxy, you can forward all DNS traffic as well!
        avodonosov 10y ago
        How do you "set the browser connection to a dynamic SSH port forward"?
- jessaustin 10y ago
  This exact issue occurred with TLS 1.2 back when BlueCoat only understood 1.1/1.0. Good grief! From David Benjamin's final comment: Note these issues are always bugs in the middlebox products. TLS version negotiation is backwards compatible, so a correctly-implemented TLS-terminating proxy should not require changes to work in a TLS-1.3-capable ecosystem. It can simply speak TLS 1.2 at both client <-> proxy and proxy <-> server TLS connections. That these products broke is an indication of defects in their TLS implementations. It's understandable that I've never heard of BlueCoat: clearly this product's success is based more on selling to executives than on quality, and it has been some time since I worked in an organization that had executives to sell to.
  - jacquesm 10y ago
    It sounds like it might be a worthwhile effort to reverse engineer one of those.
    - AlyssaRowan 10y ago
      Reverse-engineer? A middlebox? Which holds trusted secret keys and which, in its normal unremarkable operation, intercepts, parses, reconstructs, decrypts, re-encrypts, forwards, and optionally logs both confidential and attacker-controlled traffic? And is also known to be used for nationwide bulk internet censorship by regimes often called 'oppressive'? Why, doesn't it just. Please consider, very carefully, the ethics and equities issues one might face with any interesting findings here.
      - lmm 10y ago
        What's true is true - better to know it than stick our heads in the sand. If these boxes have vulnerabilities (who am I kidding, they do parsing, they're probably implemented in C "for performance", of course they have vulnerabilities), we are better off for knowing about them than not.
        AlyssaRowan 10y ago
- peterwwillis 10y ago
  The fix should not have been reversion. The fix should have been a simple workaround that if the connection fails totally and no downgrade handshake attempt was made, make a new connection using 1.2 to start with, which would succeed and the connection opened. This would be equivalent to a downgrade handshake from 1.3 to 1.2 but without requiring all products support 1.3.
  - dvorak42 10y ago
    The problem with this fix is that then as long as you have the fallback, the user gains none of the security properties of TLS 1.3 (since the attacker can always force a downgrade by sending junk to the client during the handshake) and has the additional cost of a second TLS negotiation. While there was previously this "TLS fallback" implemented in Chrome to work around buggy endpoints, this was primarily due to buggy endpoints* which was a much larger issue and difficult to fix, while these middlebox issues affect a much smaller portion of users and we're hopeful that the middlebox vendors that have issues can fix their software in a more timely manner. * TLS 1.3 moves the version negotiation into an extension, which means that old buggy servers will only ever know about TLS 1.2 and below for negotiation purposes and won't break in a new matter with TLS 1.3.
    - peterwwillis 10y ago
      Am I not correct that 1.3 got backed out of chrome for the current issue? So 1.3 isn't even there now... Which breaks anything that explicitly requires 1.3. My fix would support all cases and not break anything. Unless I missed something?
      - cesarb 10y ago
        Nothing can require 1.3, since 1.3 isn't finished yet. They were doing interoperability testing with a draft version of TLS 1.3, and nobody should require a draft version of TLS 1.3 without having a fallback to TLS 1.2.
- jandrese 10y ago
  Sometimes it is even worse than that. Some of the middleware TLS proxies don't verify the certificate before they resign the data. They completely open up your enterprise to MITM attacks, and in fact hide the fact that you are being MITMed. This came to light way back during the Superfish debacle, and some vendors still have not fixed the problem.
jessaustin 10y ago
I guess in future, TLS upgrades will be opt-in?
- discreditable 10y ago
  This is something the TLS spec authors have prepared against with GREASE. The idea is the client adds some junk version information to its list of supported protocols. To quote: "Correct server implementations will ignore these values and interoperate. Servers that do not tolerate unknown values will fail to interoperate with existing clients, revealing the mistake before it is widespread." https://tools.ietf.org/html/draft-davidben-tls-grease-00 https://tools.ietf.org/html/draft-davidben-tls-grease-00
  - throwaway2048 10y ago
    This dosent really seem to solve anything, everyone now ignores the enumerated GREASE values as they are reserved upfront, and will continue to cause failures with other extended values. yay?
    - dvorak42 10y ago
      This at least means that the developer is aware that these parts of the spec are extensible, and by explicitly ignoring the GREASE values are explicitly choosing to potentially have a broken application in the future. This is a different class of problems than developers who weren't aware certain fields were extensible.
- ploxiln 10y ago
  To explain the other answer a bit more: TLS upgrades have always been opt-in. The problem is that you have to be very clever where you put that option, or some (expensive and popular and dumb) webservers and middleboxes will just freak out and block the client. The obvious place is the TLS version number in the handshake. It can say "I support up to TLS 1.3" and the other side can say "I support up to TLS 1.2" and the obvious choice is 1.2. But again, some webservers and middleboxes, as soon as they see 1.3 there, they freak out, block the connection completely. Another idea for where to put it is in the candidate ciphers list - a "oh and I support TLS 1.3" pseudo-"cipher". The other side is supposed to just not use it if it's not recognized. Bug again, some stuff out there just freaks out. Why do they freak out? Sometimes it's because someone thought that any unrecognized bit could be a hacking attempt. Sometimes it's because the software starts as a pile of bugs and is just debugged to the point that it mostly works today (and at that time "1.3" was never seen at exactly that spot). So the goal of "GREASE" is to put random not-enumerated values in places like the ciphers list. Once a server or middlebox is compatible with GREASE, it'll be compatible with any future optional upgrade signal being present in those parts of the TLS handshake. (I'm not sure where GREASE has been implemented so far, and I'm not sure if TLS 1.3 is 100% finalized yet.)
db48x 10y ago
The long-term solution is simply not to work anywhere that insists on running a MITM attack on all of your communications.
- Viper007Bond 10y ago
  Isn't MITM required in enterprise environments where they want to filter content? Unless you want to run it client-side which isn't usually an option.
  - discreditable 10y ago
    Basic filtering can be done via passively inspecting SNI headers and terminating connections to verboten hosts. However, that's not enough for some orgs, and some software works around it: https://www.bamsoftware.com/papers/fronting/ https://www.bamsoftware.com/papers/fronting/
    - ec109685 10y ago
      Even simple tls handshake filtering is broken with BlueCoat's implementation.
  - emmab 10y ago
    > Isn't MITM required in enterprise environments where they want to filter content? Then don't filter content.
    - theluketaylor 10y ago
      At my workplace we need to use middleboxes like this for 2 reasons -our commitment to our customers and regulatory compliance requires we know where customer data is at all times. It would be lovely if all employees could be trusted with data at all times, but the reality is some employees will steal information, as google found out with Levandowski. That's google's own information though; they don't have a regulatory requirement to report the breach, whereas the data I protect requires full disclosure legally. -malware is increasingly using https to communicate with C&C. Many malware families now install a trusted root cert so they can exfiltrate data on less monitored 443 rather than 80. When (not if) devices get compromised we need to know what the attacker got. I would love to not need to do this because it's a privacy mess and breaks applications all the time, but there simply are not better tools to serve as the last line of defence against data loss. iOS has mostly solved this problem through a combination of not running unsigned code and APIs where MDM can draw a corporate data barrier inside the phone, but while desktop OSs remain there will need to be some form of this.
mastax 10y ago
Wouldn't it be better to allow enterprises to do version pinning (which I believe used to be supported in chrome enterprise), rather than remove TLS 1.3 for everyone?
- rasz_pl 10y ago
  You mean giving control back to the users of your software? Google doesnt play like that. Motership knows best! You cant even freeze chrome extensions.
xfs 10y ago
The title was editorialized. TLS 1.3 is a working draft and Chromium is just doing field trial with it. A few days ago there were other issues with this causing Chromium to stop working on *.google.com so it's not just about middle-boxes. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855434 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855434 https://bugs.chromium.org/p/chromium/issues/detail?id=693943 https://bugs.chromium.org/p/chromium/issues/detail?id=693943
- prdonahue 10y ago
  Sure, it's a working draft, but companies are actively working to develop and test their server side integrations. Having to disable it like this harms those efforts as fewer users are making connections (by default).
- coderobe 10y ago
  Not necessarily just a field trial. AFAIK it was bundled with a recent ChromeOS update, causing logon to fail when MITM'd
- dvorak42 10y ago
  While there was a secondary issue with the deployment regarding unofficial builds/derivatives, the field trial was primarily rolled back due to the number of affected customers due to the middle-box issues in their enterprise/edu networks.
- the8472 10y ago
  TLS1.3 may be a working draft, correctly implementing TLS version negotiation on the other hand is not as it already is a requirement of previous versions.
morecoffee 10y ago
Amazing how this was predicted coming on a year ago* > At this point it's worth recalling the Law of the Internet: blame attaches to the last thing that changed. > There's a lesson in all this: have one joint and keep it well oiled. > When we try to add a fourth (TLS 1.3) in the next year, we'll have to add back the workaround, no doubt. In summary, this extensibility mechanism hasn't worked well because it's rarely used and that lets bugs thrive. * https://www.imperialviolet.org/2016/05/16/agility.html https://www.imperialviolet.org/2016/05/16/agility.html
komali2 10y ago
Who's the guy with fifty thousand Chromebooks? Goodness.
- enneff 10y ago
  I'm going to guess they're a system administrator at a school or corporation.
- nl 10y ago
  They actually have 120,000. ("Upwards of 50,000 (out of 120,000) Chromebooks have updated to OS56.") They also have 46,000 PCs. So yeah - pretty decent size...
- ktta 10y ago
  Someone related to Montgomery Public Schools. Googling the domain of their email shows up the school.
- compuguy 10y ago
  School systems uses them because they are cheaper to deploy and maintain than traditional laptops.
tehabe 10y ago
I kinda hoped that TLS 1.3 had some magick in it so that those MITM proxies would no longer work because they can be recognized by the browser and the browser can say: how about no. Also, wasn't there some security issues relating to the possibility to downgrade the encryption of a connection?
dang 10y ago
Edit: oops, my mistake. Carry on. > Have some god damn ethics Personal attacks are not allowed on HN. We ban accounts that do this, so please don't do it. We detached this subthread from https://news.ycombinator.com/item?id=13750650 https://news.ycombinator.com/item?id=13750650 and marked it off-topic.
- riffic 10y ago
  This was not intended to be read as a personal attack, sorry about that. My intention was a (perhaps poorly worded) call on those in the industry to have a sense of ethics, and not meant to single any person in particular.
  - dang 10y ago
    Sorry for misreading you! I've put your comment back and detached this bit instead.
pluma 10y ago
If your (content filter, monitoring, anti-virus) software is indistinguishable from malware, maybe it's malware.
- phkahler 10y ago
  Particularly software that uses MITM against TLS.
chaz6 10y ago
It sounds like if you run a web server, you should think about only supporting TLS 1.3 with no downgrade support, to ensure security without the possibility of your visitors' being subject to interception by a third party (even if it is their own enterprise).
- chinathrow 10y ago
  That is entirely doable - if you don't care about enterprise/gov/school users using such proxies.
- mysticmarvel 10y ago
  The second party in this instance is the organisation, including the user. The enterprise owns the pipe, the router, the endpoint device, the chair the user sits on, and the time being used by the employee while they are not on a break. They are a representative of the enterprise while they use a workplace computer, and while they do have an expectation of privacy on devices under certain circumstances, that is balanced with my need to protect the enterprise from bad actors. I am obliged to MitM the significant majority of SSL connections, but I do so after acquiring informed consent from the employee. This is via both workplace policy to which they must agree to remain employed, and via clickthrough notification on logon that SSL is intercepted and use is monitored. In exchange, I will only make use of information collected that is pertinent to such protection activities. For instance, if I see a Bookface post about a party at the weekend posted during a break, that is discarded. If a post is captured that is sending business-confidential information to a competitor, that is collected and used in a formal process. If you break my ability to monitor the use of my devices, your product is dropped from my network. You'll also find that it is dropped from the entire education sector. That is why Chrome has backed off this change.
peterkelly 10y ago
From https://www.bluecoat.com/products-and-solutions/ssl-visibility-appliance https://www.bluecoat.com/products-and-solutions/ssl-visibili... > "Enterprise class Blue Coat’s SSL Visibility Appliance is comprehensive, extensible solution that assures high-security encryption. While other vendors only support a handful of cipher-standards, the SSL Visibility Appliance provides timely and complete standards support, with over 70 cipher suites and key exchanges offered, and growing. Furthermore, unlike competitive offerings, this solution does not “downgrade” cryptography levels and weaken your organization’s security posture, putting it at greater risk. As the SSL/TLS standards evolve, so will the management and enforcement capabilities of the SSL Visibility Appliance."
- al2o3cr 10y ago
  Look, connections that can't be opened are obviously 100% secure. #sales #winning
hannob 10y ago
This is even crazier than people may think on the first look. The TLS community knew that there would be problems with the deployment of TLS 1.3 with version intolerance, because there always have been. That's why the version negotiation was changed and a mechanism called GREASE was invented to avoid just such problems. But it seems BlueCoat has shown us that there's no way to anticipate all the breakage introduced by stupid vendors. The takeaway message is this: Avoid Bluecoat products at all costs. These companies are harming the Internet and its progress.
rasz_pl 10y ago
Blue Coat makes MitM/censoring devices, probably every wannabe shithole* with a dictator has it or competitors product installed. https://citizenlab.org/2013/01/planet-blue-coat-mapping-global-censorship-and-surveillance-tools/ https://citizenlab.org/2013/01/planet-blue-coat-mapping-glob... *Egypt, Kuwait, Qatar, Saudi Arabia, the UAE. Afghanistan, Bahrain, China, India, Indonesia, Iraq, Kenya, Kuwait, Lebanon, Malaysia, Nigeria, Qatar, Russia, Saudi Arabia, South Korea, Singapore, Thailand, Turkey, and Venezuela.
- dtornabene 10y ago
  Yeah, this is totally not racist in any way. Good to know all the brown people live in "shitholes". Hard to know if this trolling or just casual racism.
  - jessaustin 10y ago
    You're reading something that isn't there. Russians are like the whitest people on earth. South Korea and Singapore aren't "shitholes" by any measure. However, by their BlueCoat use, they are "wannabe shitholes". I clicked through to find you are "antifa". Didn't you get the memo? You can't be seen to defend Russia in any way!
    - dtornabene 10y ago
      While russians are, yeah, pretty white, that still reads as pretty racist. wannabe shitholes is....kinda not a good look. just sayin. EDIT: also worth pointing out, Russia is literally the only country listed that has a "white" population. So, yeah, downvote all ya'll want, that was a racist( or trolling) comment. you're totally right on that last point though. ;)
      - kretor 10y ago
        The list of countries seems to be coming from the blogpost the commenter linked: https://citizenlab.org/2013/01/planet-blue-coat-mapping-global-censorship-and-surveillance-tools/ https://citizenlab.org/2013/01/planet-blue-coat-mapping-glob...
shthed 10y ago
I wish Chrome wouldn't show a site as 'Secure' if it can tell that the connection is being MITM'd
- wolf550e 10y ago
  The server can compare the TLS ClientHello to the expected one for the UserAgent and output a warning/error.
- jeroenhd 10y ago
  This is a good point. Google has added functionality so that user installed certificates bypass all certificate pinning utilities, so users using these tools are less protected. However, there is no indication of the network being monitored once the certificate has been installed. On Android every time a user-installed certificate authority is used a warning is shown. Furthermore, the user is forced to set a lock screen the moment you install a certificate. If Google can push this (frankly user unfriendly) UI through, why not change "Secure" into "Monitored" in Google Chrome? The green padlock is a lie and the truth is exposed only after inspecting the certificate using the web developer tools.
duncans 10y ago
Many a head-scratching web application error investigation has resulted in an "a-ha" moment when you notice the `X-BlueCoat-Via` header in your logs. It does stuff like issuing GETs against URLs that only have POST handlers. It issues these random requests having procured its users' auth cookies even when the real user has since left the site.
throw2016 10y ago
There is a massive hypocrisy in browser vendors getting hysterical about self signed certs while letting MITM proxies operate with impunity or worse working with them. Why isn't there an effort to detect MITM proxies and post equally scary warnings? Surely users have a right to know. MITM is worse than self signed certs and if 'exceptions' can be found for MITM like corporate security, management etc then the same exceptions should be found for self signed certs for individuals rather than creating dependencies on CA 'authorities'. This just another instance of furthering corporate interests while sacrificing individuals.
- wolf550e 10y ago
  Why do you prefer a self signed certificate instead of using let's encrypt? You can create a self signed CA and add it to trusted roots to avoid warnings.
  - throw2016 10y ago
    Because it does not rely on any 'authority'. The increasingly scary warnings by browser vendors is in stark contrast to zero interest in detecting MITMs and warning users. The next step could very well be the disabling the ability to add exceptions for self signed certs. Why not promote content encryption or explore other ideas that do not rely on central authorities, and we can see there are always workaround for corporates but individuals are thrown under the bus.
- cesarb 10y ago
  How can a browser distinguish between a self-signed server certificate, and a MITM proxy presenting a self-signed server certificate? The scary warnings for self-signed certificates are in fact a protection against MITM. It's because of them that MITM proxies are forced to install a CA certificate. The main difference is that installing a CA certificate requires explicit action in the browser (and on some newer systems displays scary warnings), while if a MITM proxy could simply present a fake self-signed certificate, it could easily intercept anyone. Therefore, self-signed certificates are strictly worse.
dorfsmay 10y ago
Browsers should add a button which allow being proxied, combined with a campaign to educate people on the difference. I think its reasonable for a company to want to filter everything that comes through their pipe, if anything, it's a bit of a liability not to do it, but at the same time, non-technical people should understand that their connection is being unencrypted and re-encrypted, and be educated on the consequences. There are a few local coffee shops which terminate SSL, and when people see me closing my browser and laptop, or starting to tether through my phone because of the cert error they tell me "oh, you just need to accept all those certs!".
feld 10y ago
Why doesnt google have a lab of MITM proxy equipment instead of testing conformance in the wild?

288 points by coderobe 10y ago

Note that this happens even when using a BlueCoat proxy in non-MITM mode. BlueCoat tries to "analyze" TLS connections, and rejects anything it doesn't understand. This exact issue occurred with TLS 1.2 back when BlueCoat only understood 1.1/1.0. In this case, it doesn't sound like they're reverting it because of overall breakage, but rather because it breaks the tool that would otherwise be used to control TLS 1.3 trials and other configuration. Firefox had a similar issue, where they temporarily used more conservative settings for their updater than for the browser itself, to ensure that people could always obtain updates that might improve the situation.

coderobe 10y ago
Rejecting anything it doesn't understand sounds like a bug to me. If it sees that it's TLS, it should attempt a protocol downgrade. There's absolutely no reason for this to break, as TLS 1.3 exists alongside TLS 1.2 (For now).
- ehsankia 10y ago
  The surprising part (or maybe not) is that BlueCoat had been made aware of this change months ago and never got around properly testing it. This one of the softwares main purpose, and the fact that they didn't even make sure it works on the newest Chrome, leading to such a mess, is pretty sad.
  - deleted 10y ago
    [deleted]
  - nikanj 10y ago
    The way this is going to be spinned, I promise you, is: Google released a new version of Chrome, and support for that upgrade is in BlueCoat v.next. Here's an invoice for the new license+consulting services for the upgrade. In corporate environments, the last thing that changes is the thing that gets blamed. BlueCoat was not upgraded, Chrome was, and now things are broken? Not their fault.
- 234dd57d2c8dba 10y ago
  It's a security feature, often malware will send encrypted traffic over 443 in an attempt to bypass firewalls. If BlueCoat can't understand the traffic, it drops it as it assumes it's malicious.
  - theamk 10y ago
    But the traffic is totally understandable -- the right action does not require knowing what TLS 1.3 is. The way it is supposed to work is as following: there is a protocol negotiation when the connection is established (which is obviously unencrypted), which contains TLS version supported. If MITM proxy does not understand the version, it can just change these bytes to force hosts to negotiate at a lower version. So the only reason BlueCoat fails is because the authors failed to implement force version downgrade.
  - jarym 10y ago
    The Bluecoat sales people did a number on you huh? Sounds really good until you ask 'why doesn't Bluecoat understand this traffic' - because it really should.
    - icebraining 10y ago
      TLS 1.3 is still quite new, doesn't seem outrageous that they take a bit to implement it.
      - deathanatos 10y ago
        This is a failure to implement any version of TLS correctly, not just v1.3. (TLS has support for version negotiation including receiving a hello from a client with a future version, such as v1.3.)
- userbinator 10y ago
  Rejecting anything it doesn't understand sounds like a bug to me. It sounds like a perfectly reasonable behaviour if the goal is to "fail closed", to provide more security in a fashion similar to a whitelist. If it sees that it's TLS, it should attempt a protocol downgrade. I don't remember the exact details but I recall reading that TLS has a mechanism to prevent version downgrades, precisely to defend against such "attacks", so the connection would not succeed in that case either.
  - coderobe 10y ago
    Client and Server exchange a list of capabilities at the beginning of a TLS connection, if the proxy just filters out the protocols/versions it doesn't understand, server/client will agree on a different version (like 1.2).
  - ademarre 10y ago
    > It sounds like a perfectly reasonable behaviour if the goal is to "fail closed", to provide more security in a fashion similar to a whitelist. This reminds me of firewalls that weaken security by filtering unrecognized HTTP headers: https://news.ycombinator.com/item?id=12655180 https://news.ycombinator.com/item?id=12655180
  - tbrowbdidnso 10y ago
    The TLS negotiation is mutual. Both endpoints tell each other what they support and they agree on a protocol that's mutually supported. If merely advertising 1.3 while still advertising older versions causes blue coat to break, it has a bug in TLS version negotiation. There is no downgrade or whitelist or failing closed. Each end says what they support and BlueCoat blows up the connection if it sees that the other end supports a newer version. It should say "oh we both support 1.2 let's use that" And apparently it's done this before so there's even less an excuse for it.
    - rocqua 10y ago
      This is apparently a problem when bluecoat is used in non-mitm mode. That probably means bluecoat is merely inspecting the initial handshake, not modifying it. That would imply it can't actually modify the handshake. It then simply inspects a connection it doesn't understand and 'fails closed' by preventing that connection.
- jlgaddis 10y ago
  On the other hand, allowing stuff that you don't understand gives us things like the CSRF vulnerabilities in MongoDB and such. In the case of a security appliance -- such as this -- it should, in my opinion, "fail closed".
  - deathanatos 10y ago
    Sorry, no. TLS is explicitly designed to allow smooth upgrading like this. This proxy is supposed to (in response to a client hello w/ TLSv1.3) respond with TLSv1.2 if that's what it supports. This is still a rigorous parsing of the input being given: nothing is "not understood": version negotiation is an inherent part of the protocol and is supposed to allow for painless upgrades to more secure protocols. The RFC (which if you're implementing TLS, you should have open at all times) explicitly calls out exactly this behavior: > Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. The quality of this vendor's implementation is extremely suspect.
    - rocqua 10y ago
      The issue only occurs in non-mitm mode, probably meaning the box doesn't actually do the TLS handsake, instead merely inspecting it.
- skywhopper 10y ago
  It's in BlueCoat's political interests to make sure TLS 1.3 rolls out as slowly as possible since it actively works against their entire business model, so they have zero incentive to be proactive about this until the TLS 1.3 extensions are approved that make MITM possible again.
quotemstr 10y ago
Ridiculously conservative middleboxes are why we can't have nice things and why we need to encrypt all new protocols, security properties aside.
- jlgaddis 10y ago
  [ off-topic comment deleted ]
  - kbart 10y ago
    Probably you have already (mis)clicked (down)vote button on this comment before. It's easy to do accidentally, especially on touchscreen.
    - jlgaddis 10y ago
      I was pretty sure that wasn't it. I noticed it as soon as I first saw the comment. That's the simplest explanation, though, so that's probably what happened. Oh well.
- DanielDent 10y ago
  This is precisely the conclusion Google reached and has used as they work on QUIC. Even protocol state (equivalents of TCP FIN/SYN/etc) is encrypted, to ensure that middleboxes don't get ideas about what the protocol is 'supposed' to do - ideas which make it hard to change the protocol in the future.
  - CapacitorSet 10y ago
    It is really sad that one reason why QUIC encrypts protocol states is to prevent excessively eager middleboxes from meddling with the traffic.
- peterwwillis 10y ago
  Actually, no, that would just make everything more difficult. Browsers need to start coming to terms with the fact that they do not get do dictate how www networking operates for every organization around the world. There are hundreds of thousands of organizations that need inspection and caching and proxying of internal www traffic. That all protocols should disallow or frustrate this disregards real needs of users and organizations. Further still, if protocols can't be designed to be implemented easily or to allow for implementation bugs or lack of features, it's a crap protocol or application. Middleware will always be necessary, and encryption really shouldn't change the requirements of how middleware needs to work with a protocol.
mrmondo 10y ago
BlueCoat are an incredibly evil company that are breaking the internet.
- rossy 10y ago
  BlueCoat makes me cry. We have an application running inside the firewall of one of our clients that communicates with a HTTPS REST API hosted by a server in our datacenter. The connection must be encrypted because it handles confidential information, but when it passes through BlueCoat's TLS proxy, the Authorization header gets mangled and it can't authenticate against our backend. Higher-ups decided that it would be better to try to convince the client to let our app bypass their proxy than to implement a custom workaround for BlueCoat users, but the client never let us through, so the only solution we could implement involved manually SCPing the required data between client and server.
  - reacweb 10y ago
    Ssh is almost often available to connect through the firewall. Do IT people understand how easily you can work around proxy using ssh ? Just start a vm in the cloud (like a C1 at scaleway for 3.6€ per month), install squid (with default options). On your PC, run portable applications: putty connected to your vm with a forward of proxy port and portable firefox configured to use your forwarded proxy.
    - jeroenhd 10y ago
      There's not even a need for installing a proxy! SSH has native SOCKS proxy support, so all you need to do is set up an SSH connection and set the browser connection to a dynamic SSH port forward. This also prevents leaking DNS requests : with a standard proxy your computer might be trying to look up domains using the company DNS system. With a SOCKS proxy, you can forward all DNS traffic as well!
      - avodonosov 10y ago
        How do you "set the browser connection to a dynamic SSH port forward"?
jessaustin 10y ago
This exact issue occurred with TLS 1.2 back when BlueCoat only understood 1.1/1.0. Good grief! From David Benjamin's final comment: Note these issues are always bugs in the middlebox products. TLS version negotiation is backwards compatible, so a correctly-implemented TLS-terminating proxy should not require changes to work in a TLS-1.3-capable ecosystem. It can simply speak TLS 1.2 at both client <-> proxy and proxy <-> server TLS connections. That these products broke is an indication of defects in their TLS implementations. It's understandable that I've never heard of BlueCoat: clearly this product's success is based more on selling to executives than on quality, and it has been some time since I worked in an organization that had executives to sell to.
- jacquesm 10y ago
  It sounds like it might be a worthwhile effort to reverse engineer one of those.
  - AlyssaRowan 10y ago
    Reverse-engineer? A middlebox? Which holds trusted secret keys and which, in its normal unremarkable operation, intercepts, parses, reconstructs, decrypts, re-encrypts, forwards, and optionally logs both confidential and attacker-controlled traffic? And is also known to be used for nationwide bulk internet censorship by regimes often called 'oppressive'? Why, doesn't it just. Please consider, very carefully, the ethics and equities issues one might face with any interesting findings here.
    - lmm 10y ago
      What's true is true - better to know it than stick our heads in the sand. If these boxes have vulnerabilities (who am I kidding, they do parsing, they're probably implemented in C "for performance", of course they have vulnerabilities), we are better off for knowing about them than not.
      - AlyssaRowan 10y ago
peterwwillis 10y ago
The fix should not have been reversion. The fix should have been a simple workaround that if the connection fails totally and no downgrade handshake attempt was made, make a new connection using 1.2 to start with, which would succeed and the connection opened. This would be equivalent to a downgrade handshake from 1.3 to 1.2 but without requiring all products support 1.3.
- dvorak42 10y ago
  The problem with this fix is that then as long as you have the fallback, the user gains none of the security properties of TLS 1.3 (since the attacker can always force a downgrade by sending junk to the client during the handshake) and has the additional cost of a second TLS negotiation. While there was previously this "TLS fallback" implemented in Chrome to work around buggy endpoints, this was primarily due to buggy endpoints* which was a much larger issue and difficult to fix, while these middlebox issues affect a much smaller portion of users and we're hopeful that the middlebox vendors that have issues can fix their software in a more timely manner. * TLS 1.3 moves the version negotiation into an extension, which means that old buggy servers will only ever know about TLS 1.2 and below for negotiation purposes and won't break in a new matter with TLS 1.3.
  - peterwwillis 10y ago
    Am I not correct that 1.3 got backed out of chrome for the current issue? So 1.3 isn't even there now... Which breaks anything that explicitly requires 1.3. My fix would support all cases and not break anything. Unless I missed something?
    - cesarb 10y ago
      Nothing can require 1.3, since 1.3 isn't finished yet. They were doing interoperability testing with a draft version of TLS 1.3, and nobody should require a draft version of TLS 1.3 without having a fallback to TLS 1.2.
jandrese 10y ago
Sometimes it is even worse than that. Some of the middleware TLS proxies don't verify the certificate before they resign the data. They completely open up your enterprise to MITM attacks, and in fact hide the fact that you are being MITMed. This came to light way back during the Superfish debacle, and some vendors still have not fixed the problem.

jessaustin 10y ago

I guess in future, TLS upgrades will be opt-in?

discreditable 10y ago
This is something the TLS spec authors have prepared against with GREASE. The idea is the client adds some junk version information to its list of supported protocols. To quote: "Correct server implementations will ignore these values and interoperate. Servers that do not tolerate unknown values will fail to interoperate with existing clients, revealing the mistake before it is widespread." https://tools.ietf.org/html/draft-davidben-tls-grease-00 https://tools.ietf.org/html/draft-davidben-tls-grease-00
- throwaway2048 10y ago
  This dosent really seem to solve anything, everyone now ignores the enumerated GREASE values as they are reserved upfront, and will continue to cause failures with other extended values. yay?
  - dvorak42 10y ago
    This at least means that the developer is aware that these parts of the spec are extensible, and by explicitly ignoring the GREASE values are explicitly choosing to potentially have a broken application in the future. This is a different class of problems than developers who weren't aware certain fields were extensible.
ploxiln 10y ago
To explain the other answer a bit more: TLS upgrades have always been opt-in. The problem is that you have to be very clever where you put that option, or some (expensive and popular and dumb) webservers and middleboxes will just freak out and block the client. The obvious place is the TLS version number in the handshake. It can say "I support up to TLS 1.3" and the other side can say "I support up to TLS 1.2" and the obvious choice is 1.2. But again, some webservers and middleboxes, as soon as they see 1.3 there, they freak out, block the connection completely. Another idea for where to put it is in the candidate ciphers list - a "oh and I support TLS 1.3" pseudo-"cipher". The other side is supposed to just not use it if it's not recognized. Bug again, some stuff out there just freaks out. Why do they freak out? Sometimes it's because someone thought that any unrecognized bit could be a hacking attempt. Sometimes it's because the software starts as a pile of bugs and is just debugged to the point that it mostly works today (and at that time "1.3" was never seen at exactly that spot). So the goal of "GREASE" is to put random not-enumerated values in places like the ciphers list. Once a server or middlebox is compatible with GREASE, it'll be compatible with any future optional upgrade signal being present in those parts of the TLS handshake. (I'm not sure where GREASE has been implemented so far, and I'm not sure if TLS 1.3 is 100% finalized yet.)

db48x 10y ago

The long-term solution is simply not to work anywhere that insists on running a MITM attack on all of your communications.

Viper007Bond 10y ago
Isn't MITM required in enterprise environments where they want to filter content? Unless you want to run it client-side which isn't usually an option.
- discreditable 10y ago
  Basic filtering can be done via passively inspecting SNI headers and terminating connections to verboten hosts. However, that's not enough for some orgs, and some software works around it: https://www.bamsoftware.com/papers/fronting/ https://www.bamsoftware.com/papers/fronting/
  - ec109685 10y ago
    Even simple tls handshake filtering is broken with BlueCoat's implementation.
- emmab 10y ago
  > Isn't MITM required in enterprise environments where they want to filter content? Then don't filter content.
  - theluketaylor 10y ago
    At my workplace we need to use middleboxes like this for 2 reasons -our commitment to our customers and regulatory compliance requires we know where customer data is at all times. It would be lovely if all employees could be trusted with data at all times, but the reality is some employees will steal information, as google found out with Levandowski. That's google's own information though; they don't have a regulatory requirement to report the breach, whereas the data I protect requires full disclosure legally. -malware is increasingly using https to communicate with C&C. Many malware families now install a trusted root cert so they can exfiltrate data on less monitored 443 rather than 80. When (not if) devices get compromised we need to know what the attacker got. I would love to not need to do this because it's a privacy mess and breaks applications all the time, but there simply are not better tools to serve as the last line of defence against data loss. iOS has mostly solved this problem through a combination of not running unsigned code and APIs where MDM can draw a corporate data barrier inside the phone, but while desktop OSs remain there will need to be some form of this.

mastax 10y ago

Wouldn't it be better to allow enterprises to do version pinning (which I believe used to be supported in chrome enterprise), rather than remove TLS 1.3 for everyone?

rasz_pl 10y ago
You mean giving control back to the users of your software? Google doesnt play like that. Motership knows best! You cant even freeze chrome extensions.

xfs 10y ago

The title was editorialized. TLS 1.3 is a working draft and Chromium is just doing field trial with it. A few days ago there were other issues with this causing Chromium to stop working on *.google.com so it's not just about middle-boxes. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855434 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855434 https://bugs.chromium.org/p/chromium/issues/detail?id=693943 https://bugs.chromium.org/p/chromium/issues/detail?id=693943

prdonahue 10y ago
Sure, it's a working draft, but companies are actively working to develop and test their server side integrations. Having to disable it like this harms those efforts as fewer users are making connections (by default).
coderobe 10y ago
Not necessarily just a field trial. AFAIK it was bundled with a recent ChromeOS update, causing logon to fail when MITM'd
dvorak42 10y ago
While there was a secondary issue with the deployment regarding unofficial builds/derivatives, the field trial was primarily rolled back due to the number of affected customers due to the middle-box issues in their enterprise/edu networks.
the8472 10y ago
TLS1.3 may be a working draft, correctly implementing TLS version negotiation on the other hand is not as it already is a requirement of previous versions.

morecoffee 10y ago

Amazing how this was predicted coming on a year ago* > At this point it's worth recalling the Law of the Internet: blame attaches to the last thing that changed. > There's a lesson in all this: have one joint and keep it well oiled. > When we try to add a fourth (TLS 1.3) in the next year, we'll have to add back the workaround, no doubt. In summary, this extensibility mechanism hasn't worked well because it's rarely used and that lets bugs thrive. * https://www.imperialviolet.org/2016/05/16/agility.html https://www.imperialviolet.org/2016/05/16/agility.html

komali2 10y ago

Who's the guy with fifty thousand Chromebooks? Goodness.

enneff 10y ago
I'm going to guess they're a system administrator at a school or corporation.
nl 10y ago
They actually have 120,000. ("Upwards of 50,000 (out of 120,000) Chromebooks have updated to OS56.") They also have 46,000 PCs. So yeah - pretty decent size...
ktta 10y ago
Someone related to Montgomery Public Schools. Googling the domain of their email shows up the school.
compuguy 10y ago
School systems uses them because they are cheaper to deploy and maintain than traditional laptops.

tehabe 10y ago

I kinda hoped that TLS 1.3 had some magick in it so that those MITM proxies would no longer work because they can be recognized by the browser and the browser can say: how about no. Also, wasn't there some security issues relating to the possibility to downgrade the encryption of a connection?

dang 10y ago

Edit: oops, my mistake. Carry on. > Have some god damn ethics Personal attacks are not allowed on HN. We ban accounts that do this, so please don't do it. We detached this subthread from https://news.ycombinator.com/item?id=13750650 https://news.ycombinator.com/item?id=13750650 and marked it off-topic.

riffic 10y ago
This was not intended to be read as a personal attack, sorry about that. My intention was a (perhaps poorly worded) call on those in the industry to have a sense of ethics, and not meant to single any person in particular.
- dang 10y ago
  Sorry for misreading you! I've put your comment back and detached this bit instead.

pluma 10y ago

If your (content filter, monitoring, anti-virus) software is indistinguishable from malware, maybe it's malware.

phkahler 10y ago
Particularly software that uses MITM against TLS.

chaz6 10y ago

It sounds like if you run a web server, you should think about only supporting TLS 1.3 with no downgrade support, to ensure security without the possibility of your visitors' being subject to interception by a third party (even if it is their own enterprise).

chinathrow 10y ago
That is entirely doable - if you don't care about enterprise/gov/school users using such proxies.
mysticmarvel 10y ago
The second party in this instance is the organisation, including the user. The enterprise owns the pipe, the router, the endpoint device, the chair the user sits on, and the time being used by the employee while they are not on a break. They are a representative of the enterprise while they use a workplace computer, and while they do have an expectation of privacy on devices under certain circumstances, that is balanced with my need to protect the enterprise from bad actors. I am obliged to MitM the significant majority of SSL connections, but I do so after acquiring informed consent from the employee. This is via both workplace policy to which they must agree to remain employed, and via clickthrough notification on logon that SSL is intercepted and use is monitored. In exchange, I will only make use of information collected that is pertinent to such protection activities. For instance, if I see a Bookface post about a party at the weekend posted during a break, that is discarded. If a post is captured that is sending business-confidential information to a competitor, that is collected and used in a formal process. If you break my ability to monitor the use of my devices, your product is dropped from my network. You'll also find that it is dropped from the entire education sector. That is why Chrome has backed off this change.

peterkelly 10y ago

From https://www.bluecoat.com/products-and-solutions/ssl-visibility-appliance https://www.bluecoat.com/products-and-solutions/ssl-visibili... > "Enterprise class Blue Coat’s SSL Visibility Appliance is comprehensive, extensible solution that assures high-security encryption. While other vendors only support a handful of cipher-standards, the SSL Visibility Appliance provides timely and complete standards support, with over 70 cipher suites and key exchanges offered, and growing. Furthermore, unlike competitive offerings, this solution does not “downgrade” cryptography levels and weaken your organization’s security posture, putting it at greater risk. As the SSL/TLS standards evolve, so will the management and enforcement capabilities of the SSL Visibility Appliance."

al2o3cr 10y ago
Look, connections that can't be opened are obviously 100% secure. #sales #winning

hannob 10y ago

This is even crazier than people may think on the first look. The TLS community knew that there would be problems with the deployment of TLS 1.3 with version intolerance, because there always have been. That's why the version negotiation was changed and a mechanism called GREASE was invented to avoid just such problems. But it seems BlueCoat has shown us that there's no way to anticipate all the breakage introduced by stupid vendors. The takeaway message is this: Avoid Bluecoat products at all costs. These companies are harming the Internet and its progress.

rasz_pl 10y ago

Blue Coat makes MitM/censoring devices, probably every wannabe shithole* with a dictator has it or competitors product installed. https://citizenlab.org/2013/01/planet-blue-coat-mapping-global-censorship-and-surveillance-tools/ https://citizenlab.org/2013/01/planet-blue-coat-mapping-glob... *Egypt, Kuwait, Qatar, Saudi Arabia, the UAE. Afghanistan, Bahrain, China, India, Indonesia, Iraq, Kenya, Kuwait, Lebanon, Malaysia, Nigeria, Qatar, Russia, Saudi Arabia, South Korea, Singapore, Thailand, Turkey, and Venezuela.

dtornabene 10y ago
Yeah, this is totally not racist in any way. Good to know all the brown people live in "shitholes". Hard to know if this trolling or just casual racism.
- jessaustin 10y ago
  You're reading something that isn't there. Russians are like the whitest people on earth. South Korea and Singapore aren't "shitholes" by any measure. However, by their BlueCoat use, they are "wannabe shitholes". I clicked through to find you are "antifa". Didn't you get the memo? You can't be seen to defend Russia in any way!
  - dtornabene 10y ago
    While russians are, yeah, pretty white, that still reads as pretty racist. wannabe shitholes is....kinda not a good look. just sayin. EDIT: also worth pointing out, Russia is literally the only country listed that has a "white" population. So, yeah, downvote all ya'll want, that was a racist( or trolling) comment. you're totally right on that last point though. ;)
    - kretor 10y ago
      The list of countries seems to be coming from the blogpost the commenter linked: https://citizenlab.org/2013/01/planet-blue-coat-mapping-global-censorship-and-surveillance-tools/ https://citizenlab.org/2013/01/planet-blue-coat-mapping-glob...

shthed 10y ago

I wish Chrome wouldn't show a site as 'Secure' if it can tell that the connection is being MITM'd

wolf550e 10y ago
The server can compare the TLS ClientHello to the expected one for the UserAgent and output a warning/error.
jeroenhd 10y ago
This is a good point. Google has added functionality so that user installed certificates bypass all certificate pinning utilities, so users using these tools are less protected. However, there is no indication of the network being monitored once the certificate has been installed. On Android every time a user-installed certificate authority is used a warning is shown. Furthermore, the user is forced to set a lock screen the moment you install a certificate. If Google can push this (frankly user unfriendly) UI through, why not change "Secure" into "Monitored" in Google Chrome? The green padlock is a lie and the truth is exposed only after inspecting the certificate using the web developer tools.

duncans 10y ago

Many a head-scratching web application error investigation has resulted in an "a-ha" moment when you notice the `X-BlueCoat-Via` header in your logs. It does stuff like issuing GETs against URLs that only have POST handlers. It issues these random requests having procured its users' auth cookies even when the real user has since left the site.

throw2016 10y ago

There is a massive hypocrisy in browser vendors getting hysterical about self signed certs while letting MITM proxies operate with impunity or worse working with them. Why isn't there an effort to detect MITM proxies and post equally scary warnings? Surely users have a right to know. MITM is worse than self signed certs and if 'exceptions' can be found for MITM like corporate security, management etc then the same exceptions should be found for self signed certs for individuals rather than creating dependencies on CA 'authorities'. This just another instance of furthering corporate interests while sacrificing individuals.

wolf550e 10y ago
Why do you prefer a self signed certificate instead of using let's encrypt? You can create a self signed CA and add it to trusted roots to avoid warnings.
- throw2016 10y ago
  Because it does not rely on any 'authority'. The increasingly scary warnings by browser vendors is in stark contrast to zero interest in detecting MITMs and warning users. The next step could very well be the disabling the ability to add exceptions for self signed certs. Why not promote content encryption or explore other ideas that do not rely on central authorities, and we can see there are always workaround for corporates but individuals are thrown under the bus.
cesarb 10y ago
How can a browser distinguish between a self-signed server certificate, and a MITM proxy presenting a self-signed server certificate? The scary warnings for self-signed certificates are in fact a protection against MITM. It's because of them that MITM proxies are forced to install a CA certificate. The main difference is that installing a CA certificate requires explicit action in the browser (and on some newer systems displays scary warnings), while if a MITM proxy could simply present a fake self-signed certificate, it could easily intercept anyone. Therefore, self-signed certificates are strictly worse.

dorfsmay 10y ago

Browsers should add a button which allow being proxied, combined with a campaign to educate people on the difference. I think its reasonable for a company to want to filter everything that comes through their pipe, if anything, it's a bit of a liability not to do it, but at the same time, non-technical people should understand that their connection is being unencrypted and re-encrypted, and be educated on the consequences. There are a few local coffee shops which terminate SSL, and when people see me closing my browser and laptop, or starting to tether through my phone because of the cert error they tell me "oh, you just need to accept all those certs!".

feld 10y ago

Why doesnt google have a lab of MITM proxy equipment instead of testing conformance in the wild?