cURL TLS 1.3 session ticket proxy host mixup Vulnerability

Key Takeaways

guys this one is very interesting uh bug vulnerability in fact that is discovered in curl i don't i don't usually discuss vulnerabilities that are less critical like this one but i just found it fascinating because it is really depends on how the back end is configured you can run into this vulnerability and makes you just appreciate that writing front end code is not easy despite what people might have think a lot of people say hey front end code easy peasy no look at curl curl is the ultimate front end dev if you think about it it's it's all a front end that consumes lots of protocols on the back end but it's a badass swiss army knife it's just fascinating think about that and just the all these use cases that you have to kind of cater with right so if you're building something that consumes the backend if the back end changes or you can put in the configuration that is not supported things can go really wrong so let's discuss this uh title of the vulnerability is tls 1.3 session ticket proxy host mix up right uh we're going to read the blurb and then go i had a diagram uh explained here to explain what exactly this thing enabled by default lib curl supports the use of tls 1.3 session tickets to resume previous tls sessions to speed up subsequent tls handshakes this is also referred to as a zero rtt and tls 1.3 when using an https proxy and tls 1.3 lip curl can confuse session tickets arriving from the https proxy but work as if they are arriving from the remote server and then wrongly shortcut the host handshake the reason for this confusion is the modified sequence from tls 1.2 when the session ids were provided only during the tls handshake while tls 1.3 it happens post handshake and the code was not updated to take the change behavior into account so see what happened when things change right on the back and if you used to do with one thing and then all of a sudden it changes and there's a completely different code path things can go really bad so let's explain what what what what this really is so if i go to uh to this picture and i'm gonna display it in a minute i'm gonna disappear for a second here you can see that the curl or curl lab here is the client there's a proxy set up in the same machine or another different machine and have the proxy ip address set into the machine configuration so that all ip packets goes to the proxy first and layer seven content will be delivered to the actual final destination i talked about proxy versus reverse proxy right but what really happens here if your proxy is https curl or the client will establish a tcp connection between yourself and the proxy that has to happen and then since https it will follow it up with a tls handshake between the client also and the proxy so now your communication between yourself and the proxy is encrypted the first request that the client sends because it realized it's in a proxy configuration it will send something called the http connect method and i talked about it right here if you want to learn more about it that http connect method will be delivered to the proxy and the http connect method has the actual host that you want to connect to in this case this is called host right say google.com so what will happen here is the proxy will establish a tcp connection between itself and the host on your behalf right and then this is will basically be a tunnel from now on so there will be this tcp connection that you have on the front and alongside with tls will be tunneled everything that you send after that connect with it will be part of the tunnel that includes the tls actual tls handshake that you are supposed to do right now when you do a tls to the host right you will send that tls request it will immediately just forward it all the way to the host and now all of a sudden you have another tls session between yourself end to end go ahead and go into in to the host so now you have two tls kind of layered sessions here and you you tell me if this thing is not complicated enough for you right so now we have one tls session between the curl and the proxy and then another trs session between curl and the host now let's go back to the bug the bug here is uh four session resumptions to to to do a session resumption using tickets right the server will reply back with a tls extension says hey by the way let's not do this expensive tls handshake if in the future if you want to re-establish this for me we are stateful right let's just give me your ticket give me this ticket and encrypt everything you want and i'll figure out the new key right essentially the key is encrypted in the ticket somehow right and here's the but there was a confusion on the session to whom this session ticket belongs to curl didn't have that context it was just receiving tech session tickets and it thought this session ticket belonged to the proxy so what would happen here is between these two tls sessions curl got confused and started mixing up the session ticket so if you really think about what really happened here is curl lib doesn't understand who the session tech it belongs to it could belong to the proxy or the host i think it confuses it as it belongs to their host now the proxy what can do a malicious proxy can essentially creates its own session ticket ships it to curl lab as if it's belong to the host and curl it because it has this bug it will think that it belongs to the host and will re-establish the rt0rtt as if we were going to the host and now we just strict curl the client to connect to the host using our ticket so we can see everything because we built this we as the proxy we are the shady man in the middle of proxy we built that session ticket we have that symmetra key inside that ticket so we know how to decrypt it all of a sudden you see the clear text otherwise the whole thing without this the whole thing is end to end right because this is there's this big green tls session essentially so that's that's what's going on there so what was the fix the fix was if you look at the code actually let's zoom in here is to introduce a new method to know that hey am i talking to a proxy am i talking to a backend host right and based on that the parameters the session parameters will be essentially identified and as a result you would not get into a situation where the proxy sees your traffic essentially it's just just one of those things that tells me man building protocols building front end code that is resilient to these kind of uh different kind of back ends to support backward compatible back-ends right in this case supporting tls 1.3 and a proxy alongside with 1.2 right can lead to nasty stuff like this one right and this is not gonna it's not gonna be the end of this uh carl's having a bug bounty system where you can essentially try to find try to break curl lead by any other so let's credit who actually did this create work is you do [Music] mengato yang from facebook discover this all right guys that's it for me today guys this is just uh it's just these things are fascinating to me right this makes you think like building software is hard you have to think about all these situations let me know what you think i'm gonna see on the next one you guys awesome goodbye