Troubleshoot TLS Handshake Failures using Wireshark

network troubleshooting using wireshark today we're going to cover how to troubleshoot some common failures with the tls protocol using wireshark tls also known as transport layer security formerly known as ssl is a protocol widely used to secure and authenticate connections on the public internet not only that many large enterprises are also using tls to secure data between systems within their own data centers when a tls connection can't be established generally speaking it's the handshake which fails so it's important to understand the steps in the handshake if you're going to use wireshark to troubleshoot it so to get started troubleshooting the first thing i want to run through is what a good tls handshake looks like in wireshark with any sort of packet analysis and wireshark if you really want to get good at it it's important that you spend time looking at good captures or captures of good data this way you actually start recognizing some of the patterns and at the same time you can actually pick out a lot faster when the pattern doesn't hold and there may be a failure and you'll see what i mean in a sec before we get into wireshark though i want to point out two resources that i will link in the description the first is this nice guide the illustrated tls connection this is at tls.ulfheim.net and what this is is a message by message breakdown of a tls 1.2 handshake for the purpose of this video we're going to be sticking with tls 1.2 and below only because it is more widely used than any other version of tls and tls 1.3 while it is available and being used by many systems on the internet it isn't as widely used as tls 1.2 yet in future dates i may do a video on 1.3 but for now let's stick to the tls 1.2 handshake so i would highly recommend that you spend some time going through this this document will actually detail every message along with what information is passed from the client to the server or from the server to the client and you can actually use this and follow along packet capture to actually look at these messages in wireshark the second document i'll reference is the actual rfc for tls 1.2 it's a little bit more advanced if you're not really a network geek like i am but if you are or or just curious about how these protocols are constructed and designed this is really good document that goes through it literally message by message and gives you a full explanation of how it works so without further ado let's open up wireshark and i'm also going to open up a linux virtual machine which we're going to use to generate some of this data so in these examples i'm going to be using the curl command in linux to run several different tests to a public website and we're going to look at a successful handshake we're also going to look at a few problem scenarios as well so the website in question that i'm going to use as a tester for my first successful test is magicball.net this is a fan site for the 90s video game twinsens odyssey you may want to look it up so the ip address here is 213 167 243.131 so i'm going to apply that as a host filter in wireshark so i can just filter out all the other noise and just get data going to this ip and from this ip so host 213.67 243.131 okay and the second thing is i'm going to specify my data interface which in this case is my wireless there goes my filter host is 213. there it is it's my history okay so let's get started there you shouldn't see any data now until i do my first successful curl and what i'm gonna do i'm gonna do curl https www.magicball.net all right so just by looking at the curl output i can see that i see quite a lot of the hypertext of the web page itself you can see here there's some css and some actual texts and links usually when you are looking for a successful connection over tls you're looking for a connection which gets to the point where it's exchanging application layer data tls is used for multiple different apps usually people think of it only as https which is http http secured with tls but tls can actually be used for things like ftp it could be used for things like ldap etc but usually when you're talking about troubleshooting tls and troubleshooting handshakes once a handshake is successful that's when the client and the server can actually start exchanging application layered data meaning in the case of https that would be http data so in this case i see actual http http data and i'm going to assume that the handshake was successful but i can also show you that from wireshark so i've got a whole lot of packets that showed up as soon as i did that curl so let's go through it from top to bottom so the first prerequisite of a tls handshake and wireshark or tls handshake in general is that a tcp socket must be open so a tcp connection is established with a three-way handshake we see here a sin or synchronized packet coming from my virtual machine i said that coming back from the web server and then the ack so at this point i've got a socket open to tcp 443 on this server now the fourth packet in any tls connection is the client hello now the client hello is a packet that must come from the client and what it is is essentially a proposal it's a proposal for [Music] various parameters that the client can support in creating the secure connection to the web server in question so in this case if i actually open up that packet in wireshark the wireshark this section will show me a whole bunch of information that is included in this client hello or included in this proposal there are things like the tls version you've got some random data which is used for key generation a session id you've also got a list of cipher suites which is going to come up later now cipher suites are essentially uh different protocols which define the encryption which will be used in the eventual connection as well as the authentication methods which will be used in the connection as well when i send the server a list of cipher suites and also when i send the server the version i support what i'm saying is here is what i can support i can support up to tls 1.2 and i can support all of these 31 cipher suites so that proposal goes over to the server for them the server to look at it and say okay well i can i can do tls 1.2 that's good and i want to use this cipher suite or this cipher suite etc um there's lots of other information included in the client hello as well as lots of extensions which are really interesting but we're going to skip them for today so the client hello sent out it's acknowledged by the remote web server and this is really important you've got here an acknowledgement that has no data in it so like we consider this naked ack a naked ack is really just the tcp layer saying i got this packet back to the sender it's not saying that whatever is in this client hello is acceptable right so the remote web server is not saying okay um i like your parameters that you're sending me the client hello this is good acknowledgement is really just acting at layer four in the osi model which is the transport and it's saying in tcp speak it's saying i'm acknowledging that i got this now let me process it and i'll get back to you and we're going to see that come up several times in this example as well as the problem cases so in response to that client hello if the server uh is okay with the proposal in the client hello the server will send its server hello and there's a lot of many similar fields in the server hello to the client hello so we have another version which means that i've settled on version 1.2 so that's good and you can see here with cypher suite we don't have a list but we have a specific cipher suite that was chosen this cipher suite was actually chosen out of the list which the client sent over so if i actually pull this up c02f is right here and that's going to come up again in one of our problem scenarios after this so the server hello comes in it'll say we're going to do tls 1.2 we're going to use this cipher suite to do it we've got some extensions which we can look at later and again we see the response to that is just a naked ack so the client's saying okay yeah you sent the server hello i got it i'm going to acknowledge that i received it the second thing the server is going to send is its certificate now tls is used not just to encrypt and secure a data stream between two hosts right it's actually used for authentication as well so what this means is that when i'm trying to connect to remote web server say google.ca i want to make sure that that web server is actually google as opposed to um you know some other third party who's masquerading as google i want to make sure that server belongs to google and that is accomplished using um public t cryptography and certificates so a certificate is attached to a specific web server that you're connecting to and when you're trying to establish a tls connection the server needs to send you that certificate and the client has to look at the certificate analyze it and say do i trust that this is google.com or in this case magicball.net or do i not trust it in which case i don't want this communication to go forward wireshark when you actually look at the certificate packet actually breaks down the certificate into all of its individual fields so you can see here for example the common name of the cert in this case the magicball.net you can see here things like the algorithm used for the encryption you can see here the issuer of the cert is listed the validity of the cert is listed uh etc you can also see that the server sent not only the certificate for magicball.net but it sent its intermediate certificate as well in which case this is let's encrypt which is a free certificate authority so the responsibility of the servers to send the cert and in this case the intermediate or root cert responsibility of the client is to analyze that and say hey do i trust it is it valid is the certificate authority legit or is it some kind of random ca that i don't know and if it likes all that information then it will accept the cert and we can move on so you can see here in packet nine we've got another naked ack so the client's saying i got your cert the server then sends two more messages server key exchange and server hello done in this case it combined both of those messages into the same packet which is why it's in the same line here but and wireshark lists both messages with a comma we get another naked ack at that point the client's turn is up and the client has to send the client key exchange client change cipher spec and an encrypted handshake message finally the server will do another response to that it'll send its own change cipher spec and encrypted handshake message and at that point the actual application data can flow back and forth which you can actually see here because wireshark will flag it as application data now this last stage where you see change cipher spec change cipher spec is really important the change cipher spec messages are really the end of that handshake and usually when i'm analyzing a pcap with tls and looking for handshake problems whenever i see each side the client and the server send the change cipher spec message to the other side that's generally when we can say okay the handshake is finished now we can start exchanging application data it's all going to be secured and we're good to go so i usually use that as a method of detecting that the handshake is done and sure enough you can actually see after that point we see lots of full-sized packets being sent and acknowledged back and forth and this is going to be that http data which we saw within the curl so from top to bottom we've got again the three-way handshake a client hello server hello server certificate server key exchange server hello done client key exchange change cipher spec and then exchange cipher spec from the server if i go back to that web page quickly you'll see that a lot of the names here match up to the names we just went over in wireshark so you can spend some time going through this to look at the definitions of precisely what's in each of these messages besides the few things i pointed out all right now that we've covered what a successful tls handshake looks like we're going to jump into some problem scenarios that you may encounter when you're trying to establish a tls connection and it's failing so the first one we're going to look at is what happens when you're trying to establish a tls connection on a port or tcp port that's not actually running tls now tls is not specific to a port a lot of times when you mention tls people think tcp 443 tcp 443 is generally the standard port used when you're making a https connection which is http secured with tls it doesn't necessarily have to be that port though like i mentioned earlier tls can be used for securing ftp connections uh ldap connections really any tcp protocol can in theory be secured with tls one of the prerequisites of that though is that the server in question that you're connecting to actually has tls enabled on the port you're connecting to so in this case what i'm going to do is a curl to the same website magicball.net and it's https when specifying that i want to do a secure connection but i'm telling it to use port 80. now generally in http port 80 is reserved for plain text connections for http um so let's see what happens when i say to that web server hey let's do a secure connection on your plaintext port all right so we get this generic error from curl ssl routines ssl 3 get record wrong version number so who knows what that means that may be an error message that shows up in a server log or an application log of yours and you're not necessarily sure what it means so you take a packet capture and you look at it so wireshark shows a stream of data that doesn't actually look like a tls handshake at first glance you see the syn synack ack so the actual tcp socket is created that's a good step but then after that it doesn't look like you see like the client hello for example or any other tls message you get this http response back from the server um that says 400 bad request and then you see the connection fin so clearly the connection doesn't go anywhere um you don't see a whole lot of data through the connection and it's closed pretty quickly but it's good to understand why so um one of the tricks that i want to show you is that i know from this example that i'm trying to connect to this port on tls uh wireshark by default when it's trying to do the dissection of the data won't know that you want to look at what tls looks like on port 80. it sees that you're connecting the port 80 and it assumes okay this is port 80 it's plain text http so that's how it's dissecting or interpreting the data and showing you what it what the output looks like in this case it shows you for example we've got a http battery quest here so in order to um to actually dissect this as tls what i've got to do is actually go over to the tcp layer here so you can either select any of the packets go down to the tcp layer right click and then click the code as and then from here you've got to select the value which in this case select the destination port which is the application port in this case it's 80 and then under current you want to change this down to tls go to okay and right away you see that this fourth packet here actually turned into a client hello now this didn't actually change any of the contents of the packet what it did is wireshark is just interpreting it using a different filter so in this case it's interpreting it as if this was a tls packet and it's actually showing you and dissecting all the tls fields for you whereas it wasn't doing that before now you can see here we've got the cincinnati the client hello goes out that's the same client hello we saw before cls 1.2 we've got 31 different suites we see that the remote server sends a naked ack so again this doesn't mean that it likes the client hello it just means that it received the client hello and then immediately what we see is a response to it with an http 400 bad request meaning i don't know what the request is you're sending me and i'm going to tell you it's bad and then i'm going to close the connection which is what happens here with the fin and then we reply with the reset so the way you can interpret this is is that in any tls speaker it has to understand at the very least client hello and respond to it in some way either it responds to it negatively and because it doesn't like something in the client hello which we'll cover next or um it just doesn't understand it because it's not speaking the tls protocol and that's the case here you can see this service port tcp 80 is actually expecting just the plain text http protocol so when we connect to it using tls and send the client hello it doesn't know how to interpret it and then sends http 400 bad request so if you ever see something like this in a packet capture what you can do is check on the server side to make sure that the port that you're actually trying to connect to has tls enabled for http it's a little bit simpler because you've got 80 and 443 it's pretty standard one is plain decks and one's not but you might be trying to enable tls on say you know a port for microsoft exchange or for ldap and in those cases you may think that you have tls enabled but then you look at a packet caption you say hey my client's sending a client hello but the server is coming back with something like this let me check the configuration to make sure that tls is actually enabled all right so the second scenario we're going to cover is what happens when the port question you're connecting to is speaking tls but there's something that the server doesn't like about the client hello that you're sending either it doesn't like the cipher suites that you're offering to actually encrypt and authenticate the connection or it doesn't like the version you're sending so to simulate that again we've got the capture refreshed we're going to do a similar curl i'm just going to clear off this console to magicball.net in this case i'm taking out the port 80. but what i want to do is specify a cipher list so for the ciphers i'm going to specify triple des this isn't just going to use one cipher there's actually a list of ciphers associated here but for the sake of this illustration i just want to show you what happens when you have a limited cipher list so let's hit go now again you've got curl error saying that the handshake has failed which is good that tells you the handshake failed but it doesn't actually tell you why it failed this is where wireshark is useful so looking at the actual packet capture we see we have our three-way handshake since ack that's all good client hello is good naked coming back saying hey web server got the client hello which we'd expect but then immediately after that packet we see an alert let's say alert level fatal description handshake failure so clearly this is what curl was picking up there is a handshake failure the handshake doesn't get to the end which is the two change cipher specs so we've got to figure out what's going on so if i open up this client hello packet and i actually go through it i can see here the version is 1.2 but the cipher suites there's only four suites if you remember from the previous examples there was something like 31 different suites we were offering not only that these suites that are being offered are pretty legacy i don't know of any modern web servers that run any of these suites especially the empty renegotiation one now as we mentioned when we looked at the healthy handshake the server that you're connecting to has to support the version you're connecting on as well as it has to support at least one of the cipher suites that you're sending and in this case the remote server doesn't support any of these cipher suites and what happens is immediately after the client hello you get the alert from the server and then the connection is closed now if you ever want to validate this i'm going to post a link in the description to ssl labs ssl labs is a site that you can use to actually assess the tls parameters of a website on the internet so uh ssl labs allows you to plug in say magicball.net and it'll spit out all the versions of ssl or tls i should say that it supports as well as the the cipher suites it supports and a lot of other information about tls on that server but for this example you can see i've got three legacy cipher suites clearly the other side doesn't like these and need something that's a little bit more modern and then it alerts and closes the connection so if you run into this scenario uh what i would say is you need to check on the client side to make sure that the client is configured to send multiple cipher suites more the better because that may get more chances of the server accepting it but also keeping the certificates or sorry the cipher suites update because over time certain cipher suites are introduced to the tls protocol and other cipher suites are removed for security purposes so it's always important to maintain the either the actual specific configuration in your app for ssl on the client side or just to keep your ssl libraries updated if you're doing some kind of custom application so for our third failure scenario we're going to look at what happens when as an sso or tls client you're connecting to the server and the certificate presented back to you is not trusted by the client so in this case what i'm going to use is a different website it's a website bad ssl.com this website is also a good resource if you're trying to learn about ssl or tls and it will actually give you links to multiple different subdomains that all have different ssl failure conditions on them so you can actually use this to test out client software but you can also use it to learn how ssl and tls looks in wireshark so what i'm going to do the ip of this is a little bit different so let's actually just do quick ns lookup to make sure okay 104 154 85 109 85 105. 89 105 there we go okay do it in the wireless connection now instead of ns lookup i'm going to do a curl now in this case curl is smart enough to be able to tell you that there is a certificate problem and it's telling you that it is a self-signed certificate um you may run into this scenario and not actually have a error log that is as descriptive as this which is again why wireshark comes into play so let's look at the peak app so we've got cincinnati client hello naked ack that's all good in this case we actually get to the server hello so the fact that the server is actually sending back a server hello you can imply that it accepted what was in the client hello namely the the version and the cipher suites were accepted as well as whatever extensions are listed here are compatible with that server so it's good that we actually see the server hello packet come in because it means that we've gone past that stage and we're going to decide on a few things going forward so the server hello decided we're doing tls 1.2 it's decided we're going to choose the cipher suite here c02f and then in that same packet we've sent the certificate as the next record so i'm actually i can actually close down the server hello record and just look at the certificate record so the certificate is listed here and right away i can see here the common name is startup at ssl.com organization is bad ssl and then if i'm going to look at the issuer i can see that the issuer is actually bad ssl.com themselves which is the definition of a self-signed cert so depending on your client configuration if your client is secure or even public facing or anywhere on the internet it should not accept self-signed certificates unless explicitly configured to do so you may see this show up in a browser sometimes when you connect to a website or even you're running like a local web server and you don't have a certificate attached to it um you may get an error in in your browser saying something about a self-signed cert uh this is what that is uh however again if you're troubleshooting something where you don't get a nice error message you may have to look at this and say hey um i'm getting the cert but i'm not getting an intermediate cert with it i only get one certificate i'm not getting the root certificate and when i actually look at the issuer of this it's actually issued by itself so you can see that that packet is acknowledged by the client but in this case the client is the one that actually sends the ssl alert and it'll actually send it with a description saying unknown ca don't count on this happening different implementations of ssl and tls don't have this description actually included here in plain text for security reasons so get used to actually looking at the certificate and going through it and trying to pick out different reasons why it would be invalid the other major reason i find a certificate isn't valid is when the validity has expired so the validity is the window of time in which this certificate is valid you'll see it listed as a not before time and a not after time this is really the range of time that the certificate should be considered okay by your client so 2019 october 9th to 2021 october 8th is the validity period um looking at the date we're in that period of time so um at least from the date perspective the certificate is fine but we've already identified that it is the um the fact that it's self-signed that is the problem and that's why the clients close again so in this case um you would have to look at the cert server side go into the certificate figure out do i have an expired cert do i i'm not including the full certificate chain of the intermediate and root um and troubleshoot from the server side to see what you can do to resolve that but the client is doing what it should it's not accepting that cert and it's going to close off the connection so that's it for tls troubleshooting with wireshark i hope you found this video useful and if so please subscribe and like below this certainly isn't the extent of troubleshooting you can do uh with wireshark when it comes to tls but i hope this is enough to get you started at least starting to take some packet captures um of tls connections and start digging through them either the good cases uh or some problem cases if you're running to some chronic chronic problems if you are troubleshooting a network problem and you want to get some advice on it feel free to post it in the comments uh and maybe we can go through it together or even look at the packet capture and analyze it here together in the channel take care everyone and we'll talk to you next time

Channel: Plaintext Packets

Views: 2,968

Rating: 4.9191918 out of 5

Keywords:

Id: cR5CO0wSZLs

Length: 31min 33sec (1893 seconds)

Published: Fri Mar 12 2021