BSides DC 2014 - Fighting Back Against SSL Interception (or How SSL Should Work)

good afternoon i'm jacob thompson a security analyst at independent security evaluators and we're located right nearby in baltimore we do a variety of software security assessments and occasional hardware for a variety of large and small companies did anybody go to the so hopelessly broken router competition yesterday and on friday upstairs that was also part of our same company if anyone had gone to that so this presentation is fighting back against ssl interception or how ssl should work but with the poodle bug that came out last week that google presented it should be called tls interception because ssl 3.0 should be disabled now because of that bug it's a design flaw so just a the title should be revised

so a quick overview here i'm going to go over the high-level view of how ssl works in normal operation when there's no attack taking place in the protectionist protections that it has in place how ssl interception is performed today and potentially in the future with and without the cooperation of certificate authorities and how that changes the security model of the internet substantially some of the other techniques that have been presented and that are being put in place today by other parties to try and frustrate attempts at doing ssl interception then a technology that is out there and known about but i would say under use which is client certificates or mutual authentication and how this as a bonus

can help us to thwart or prevent ssl interception or at least make it much more difficult and a proof of concept website that i've developed that uses this technique so in normal operation when you connect to an ssl enabled server you're performing encryption but encryption without verifying the identity of the other party is the classic key distribution problem without some form of identity verification of man in the middle attack can be performed redirecting your traffic to some third party where they decrypt and re-encrypt it send it on to the original destination to see what's going on normal ssl prevents this by requiring the server to identify itself using a certificate the certificate is just in normal cases

an rsa public key some identity that is bound to in a signature that signature is put in place by a certificate authority certificate authorities can be hierarchical there's a chain in place where one certificate can be signed by another and so on until you eventually reach a trusted root certificate authority the trusted root certificate authorities in your browsers or other software are determined by the company that makes them or built them mozilla has a process for determining what certificate authorities are trusted microsoft and apple do as well so in essence what happens when you connect to an ssl enabled server is has some certificate authority that your software trusts is there a chain down to

the server certificate showing that through entities that i trust your identity has been verified the domain name matches a domain that you truly own increasingly and this is well this is presenting how man in the middle attacks will be prevented a normal man-in-the-middle attack if you use software like burp suite or medium proxy the reason that you can't use a server certificate is because you need the private key that goes with it to do the ssl handshake so what the software does is they create certificates on the fly that are signed by some certificate authority usually just a custom handmade certificate authority that that software creates on the fly it's not trusted because there's no company

behind it that's in that list of trusted cas so your browser generates a warning when you're using software like burp suite this is showing the client verifying the certificate against that store of trusted cas it doesn't work but increasingly on enterprise networks a system like this is in place because more and more websites have gone to using ssl everywhere rather than just the login page which was more popular just a few years ago enterprise networks are concerned and probably for good reason about what kind of company data might be leaving their networks over those encrypted connections you can think of examples like gmail facebook other social networking websites that have gone to this ssl on

everything model so these companies have bought a system that sits on their network and as outgoing connections to an ssl site are made it performs the man in the middle attack it looks through that traffic for potential keywords patterns matching credit card numbers credit card numbers social security numbers who knows what now they can't do this with that warning on everybody's machine if you think back to the man in the middle attack so the conventional ssl interception requires that the company operate this own certificate authority and install that certificate on every single machine on their network on windows they might use something like group policy mobile devices they might use a mobile device management system

mobile devices and bring your own device are where i believe this starts become problematic because your employee's view of who owns a device off work time on work time what if they leave that job and the mdm software is not removed what if they hand down the device to a sibling or someone else in their family and the software is still on there i've even thought about what if on off work time they're complaining to some government agency about their employer and that's being captured and logged there's all kinds of problems that i can contemplate here but rather than go into those i want to talk about the certificate authority model and how it is starting to be starting to be

undermined rather than what i just showed you increasingly this is starting to be the case where a certificate authority lends its trust out to some entity for the purpose of performing ssl interception this could happen with or without the certificate authority's cooperation what a large company can have is what's called a sub ca this is a certificate authority that they use internally rather when they need an ssl certificate rather than sending individual certificate requests to a public ca and having to do the billing one by one and so on they will rent out this sub ca they're intended to be used only for domain names that the company truly controls but increasingly what's been happening

is those sub cas are ending up in these ssl interception devices two years ago the trustwave example was where a publicly trusted certificate authority which was trustwave explicitly permitted one of their customers to build one of these devices and put their certificate authority in it for performing this interception and logging these other two cases just happened in the past year these both happened without the certificate authorities cooperation in this case the company on their own decided we have the sub ca we need to do ssl inspection let's put them together so we don't have to install these certificates everywhere both of these incidents were publicized fairly widely when they happened and the solution so far has just been

legal and contractual restrictions on the cas mozilla is currently undergoing an attempt to rein in their certificate authorities remind them no you're not allowed to do this but because root cas are trusted for 10 20 years if you look at your list i think it's going to be a long time before that actually happens the technical solution that is available but is not used and has some implementation problems is name constraints currently you either are a certificate authority or you're not nothing's wrong with the turkish certificate authority signing a dot gov site currently name constraints would try to fix this so that when a sub ca is issued it can have some pattern in that certificate

with wild cards potentially saying only domain names matching this pattern could ever be chained to this ca that is still years away it seems so what are other parties trying to do to make ssl interception more difficult google is really taking the lead on this one of the technologies that they put into chrome and firefox is now implementing as well is certificate pinning where on top of the existing certificate authority model you add another layer of sanity check where the google browser and now firefox are bundled with a list of well-known high-profile websites and the fingerprints of certificates that are acceptable if you encounter a publicly trusted certificate that goes to some key or certificate that does not match

that pattern it reports it to google that's how the turk trust and ansi incidents were both detected so just to remind these other than the trustwave incident both of these had to be caught and detected after the fact it's not like a company or ca disclose like okay we made a mistake we let this happen let's fix it both of these were caught by these mitigations that have been put in place another technology is that when the google search engine is crawling the internet it keeps a log of the certificates it sees they do some statistics based on those the eff has another project called the ssl observatory that is similar they have a big graph

on their website showing the interlinks between different cas and the large companies that possess a sub ca some of them are not even in the technology business like ford motor company can sign arbitrary certificates if they wanted to another thing that is increasingly common is mobile applications if you have a native mobile application you control the ssl library you can replace the built-in list of trusted cas with one of your own if you operate the ca yourself as long as the private key is not compromised nobody else can issue a certificate that's trusted against that list the thing that all of these have in common is that they all operate on the client side and this ssl inspection model if you

think about it making it acceptable is all based on having the end user sign some kind of acceptable use agreement that says your traffic will be monitored for unauthorized use this system uses logging and so on nobody's checked with the server side or the entity operating that server to say are you okay with us breaking the end and encryption you've been putting in place so what is something that is not revolutionary but builds onto existing technologies that can be fairly straightforward put in place to try and make ssl interception much more difficult is mutual authentication in mutual authentication both clients and servers have a certificate your server will present its certificate your client presented certificate both

sides have a list of trusted cas to verify each other client certificates are actually used in many cases for example in estonia every citizen has a smart card with a certificate on it and many government websites or military websites would be far more likely to use a system like this as far as public facing general public websites i've never encountered this myself so what happens and usual when mutual authentication is in place is that there's some third-party certificate authority just like for servers that instead issues certificates to clients this all builds up on the x 500 system goes back a long time originally it was envisioned that the telephone company would maintain some kind of directory of

these certificates it doesn't work that way so the problem in trying to implement a system like this is that there's no certificate authority that's widely available to issue certificates to clients that users are familiar with at least but how if we implemented mutual authentication would it stop ssl interception when this is attempted the ssl interception device will be able to make a certificate for the server that's acceptable to the client it controls the list of trusted cas on the client but when it goes to make a client certificate that's acceptable to the server it has no control whatsoever of the list of trusted cas on that server so the best thing it can do is try and

obtain a certificate from one of those case even if a commercial certificate authority helps with the service certificate it doesn't make any difference for the client one i'm going to present a solution here where we abandon this idea of trying to have some third party authenticate the client before issuing them a certificate instead the server will act as its own ca for the client certificates if you immediately think about it the difficulty is how can that server distinguish between the true end user and the man in the middle device i've thought about a enrollment process where you have some out of band channel to exchange a key that makes it difficult but not impossible for this

man in the middle device to obtain that client certificate and send its own public key to obtain it so this is a potential certificate enrollment process this builds on top of key generation tags that are built into web browsers and have been there for many years just under used when a certain form is submitted to the server the client web browser will generate an rsa key pair public key private key the private key will be stored in some kind of local protected storage the public key is sent to the server then i'm going to send an enrollment key out of ban for this example of using email for more security you could use some kind of mobile application that

creates some dedicated channel using its own certificate pinning strategy potentially then the server will send the certificate back to the client normally a certificate has no need to be encrypted it's all public information in this case it's going to be encrypted using that enrollment key just for the purpose of making it more difficult to obtain it fraudulently finally the client on the client side in javascript will decrypt that certificate using the out-of-band key and install it into the local certificate store at that point you can access the website and mutual authentication will succeed this model is used for firefox and safari on chrome it's slightly different because there's no way to install a certificate using javascript in the

testing that i was doing i instead encrypt the public key once again it's public information the only purpose in doing that is that you have to have that out-of-band key for the enrollment process to succeed i have an example website where this is in place and i can show a demonstration here so it's https mutual.securityvaluators.com if you try to go to that site it's going to test your browser to see if you have a client certificate if not is going to put you into this enrollment process so let's start it

so we have a firefox web browser open yep so i'm going to try to go to https mutual.securityevaluators.com now i actually have two subdomains on this website mutual.securityevaluators.com does not require client certificate authentication i have another domain www.mutual.com that does in a real system you would get domains that were far more intuitive as to the distinction between them than that but in this case i was able to use the same certificate twice if we look at this code here what's happening is it's attempting to load an iframe from that domain that requires mutual authentication if that had succeeded that iframe has some frame busting code in it that would have redirected you to the mutually authenticated part of the

site because of the same origin policy i can't determine from here whether that succeeded or not so i just use a time delay if this page has not been redirected within two seconds we're going to assume that mutual authentication must have failed and invite the user to begin this enrollment process so let's do that what this is going to do it's prompting you for an email address in this case for some other method to send you this out-of-band enrollment key so i will give it an email address i have a captcha in place just for sanity purposes for the proof of concept in a real system you could say that the captcha is part of the method that you

put in place to make it hard for an automated system to break this if you answer the captcha successfully i'm going to get a enrollment key sent to my email account

all this is is a 128-bit aes key that's securely generated we'll copy and paste it into this form after choosing our browser when i click this it's going to cause my browser to generate an rsa key pair you'll see a dialog flash very quickly you can barely see it that actually was all generated by the browser i did not generate that dialog box the keygen tag is part of an html form generates the key pair includes the private key and or the public key in the form submission but what i did is i've sent that to the server the server has now responded with an encrypted certificate which is here i need this out-of-band enrollment key

in order to decrypt that so i'll put it in completely client-side is going to decrypt it and install it into the browser once again i didn't generate this dialog box when the server or client receives the certificate with the correct content type it's going to immediately install it in the certificate store we can verify that by going to our certificates list this for a digression is the list of trusted certificate authorities you can see this turk trust is still there the french certificate authority which i can't remember its alphabetical name is still there so what is the penalty when a certificate authority violates its trust model and allows some entity to generate fake certificates nothing in the long term at least

my client certificates are listed under this tab this shows a certificate that the server issued if you look at the certificate authority that issued it this is not a publicly trusted certificate authority there's no one for the man in the middle device to go to and convince to into issuing a fraudulent client certificate now that i have that certificate in place if i try to go back to the beginning which you can see the url at the bottom this time that iframe will work this is another dialog box that the browser generated itself it's saying the server you're connecting to has presented me with a list of acceptable client certificate authorities you have a matching certificate do you

want to use it or if you have more than one qualifying certificate please pick one in this case we only have one well i waited too long this time the mutual handshake worked the server was able to generate a web page containing information from that client certificate in a real website you would use that to allow the user to bypass some security process or at least record the fact that they successfully authenticated using a client certificate i have much more confidence in this authentication or login session now comparing this to some of the other security measures that a lot of websites have put in place security questions security pictures one-time passphrases all of those work within the ssl session

so a man in the middle device can see all of those going past security questions i think are even worse than passwords because if you've answered it truthfully it probably never changes they're used across multiple sites these devices that are sitting in the middle will be able to see the answers so if you want to try out this website you just go to mutual.securityvalue if you go to justsecurityevaluators.com and click on knowledge there's a write-up explaining many more details and implementation issues about this in the meantime does anyone have any questions

yes

right so there's you could go in two directions one is you add a more sophisticated channel like that rsa token so long as it's not just a number that's submitted over that on over that channel that's being intercepted what in what i'm envisioning this out-of-band channel does is if you're an entity trying to perform some kind of large-scale ssl interception and you have to break that out-of-band channel every single time one it's going to be hard to do that robustly right so you've got to break different kinds of email systems potentially get it at the right time if you go through this enrollment process successfully on this network and then i move to your network and it's

already happened the client might be tipped off that they're being forced through the enrollment process again but the overall view is i'm believing here that you might be pushing that entity into having to perform a phishing attack or some other kind of more active attack that legally could put it across the boundary that people might have the ability to complain about it anybody in the back yeah

right

well i agree that this is convoluted but more and more a lot of websites are starting to do this one-time passcode anyway with your email so is it i wouldn't say it's that much worse as far as the single sign-on is what you're basically proposing i think it would make it much more usable should the single sign-on entity be trusted right so now you've reintroduced this problem where there's a third party that could be willingly or coerced into issuing a certificate fraudulently however if single sign-on can work between facebook and people that trust them or between google and others that trust them there's no reason you couldn't build a client certificate model on top of that

sign-on system yes

well they could do they could do a couple things already they have the capability to white list banking sites that they don't go through this device they could do that otherwise it's not you're not creating any kind of bypass for the system in fact this whole process will fail if one of these devices is in place so you're basically cordoning off your server from entities that are going through an ssl interception system so the worst that it can do is break functionality on those networks cause people to start complaining i don't know that they would try to stop people from doing encryption right i mean what would be more likely to cause them to do that is if you do some

kind of making your own secure channel and javascript that now you have the crypto js stuff that might start happening as well i think that would make them more alarmed than ssl which is can be broken in a pretty standard way if you have these certificates in place any search any questions from this side

okay i guess we'll close it down then yeah thanks