Do you
really believe you have end to end secure connection with your bank when you
access your account from the office? Think again. This got me into some
research, esp after a few dates later an announcement from CloudFlare came out. Here
are the results: there are at least two
scenarios for TMITM (Trusted Man In The Middle) HTTPS interception.
The corporate
firewall case.
In
corporate networks users typically access Internet via an explicit or
transparent proxy. This allows enterprise IT to maintain some degree of control
over the traffic (blacklisting untrusted websites, cut out dangerous web
scripts/ads or simply cache popular content to save uplink bandwidth). It’s pretty
obvious when it works over plain unencrypted HTTP, but HTTPS assumes end-to-end
encryption and endpoint validation! Even if proxy were there,
there are two fundamental problems:
1. Why would I trust the proxy’s
certificate?
2. The proxy’s certificate will be issues
in proxy’s name, not the target website’s name.
Seems
logical, in the end – this is the intended use for HTTPS: prove authenticity
and prevent eavesdropping. Well, let’s have a closer look:
1. Problem
#1 does not really exist in corporate environments that have their own CA
infrastructure. Most likely, each corporate device will already be configured
to trust the enterprise root CA, and thus, everything that is signed with root
CA certificate. This is why this kind of trusted MITM intrusion is
possible.
2. But what do we do with the
certificate names? Enter MITMproxy (and the like, this is not the only tool out there that does it).
This open-source piece of software does a simple trick: it allows you
to dynamically generate certificates on the fly! This way, when you
talk to, say, your bank, instead you really talk to the proxy, that presents
the certificate that you trust in the name of your bank!
Thus,
the initial quote holds true.You can trust
your HTTPS connections at work only as much as you can trust your IT
department. Workaround would be using a browser like Firefox that allows
configuring its own list of trusted certificates (independent from the OS) and
supports Certificate Pinning (which also was announced not
that long ago). Or, of course, don’t use corporate device on corporate
network for non-corporate business but who would follow these stupid
restrictions, right? :) VPNing might also help, as long
as it’s not SSL-based :)
The
CloudFlare cloud HTTPS proxy case.
OK, so
in the first case we had our Enterprise
You
can read the Nitty Gritty Technical Details here, but what’s important
for us, is that in this case even the destination, online banking for example,
server is not actually owned by the bank! Good news is that it’s owned by
someone the bank trusts and allows them to act on their behalf.
This
implementation is more clever that the previous case, since there are no
spoofed certificates involved. In fact, all the authenticity checks are carried
by the target server (i.e. your online banking server), but the session is
established to the proxy. The goal is noble – to allow cloud data offload and
protect from DDoS attacks. How long will it take for someone to device a
server-end identity hijacking without even having to steal private keys – I
don’t know. Hope it will take long enough :)
Summary
and conclusion
There
can be at least two MITM proxies in your seemingly ‘end-to-end secure and
authenticated’ connection. For now, both of them must be trusted, albeit by
someone that is not you, but your boss, your admin or your target service
provider (online shop, bank, etc).There is no such thing as privacy on the
Internet. Get used to it, if not already
.
Source : arsenb.wordpress.com
No comments:
Post a Comment