Decrypting Decryption (Episode 24) Learning Happy Hour

hello everybody welcome to another episode of learning happy hour I'm your host Mitch densely Jason Yates is with me as well and I got a good friend shaktimaan Kumar here with us and Shakti what is this hieroglyphic you've drawn here I I don't understand this what are we looking at so we're going to talk about how the Pollard and it works firewall does the decryption which is something a lot of people want to know so we basically will go through a basics of how SSL handshake happens first to get an idea of what SSL handshake is and how the data gets encrypted and transferred over and then we talked about how the firewall handles that SSL handshake and does the proxy nice okay and that's all this yeah today I can't wait to see how this pans out awesome well show us [Music] I like Mitch and Jason talked about that we are going to discuss the SSL decryption but before we start decryption we need to understand how the SSL handshake itself works that gives an insight of how decryption is even possible so we'll take a scenario where we have a PC and we call this as a client and this client wants to talk to the server which could be anywhere in the internet and we can just give any random server let's call the server name as panthulu calm now one of the common aspects of an SSL is basically a tunneling protocol but as a turning protocol we need to have encryption for sure but we also need to have authentication and we need to also be able to verify so we do hashing so one of the methods in which the SSL handshake makes the data secure and authenticated and verifies the integrity is called certificates and so I'm going to take an example of a certificate let's say there is a root C it could be any public root CA we can have an intermediate root CA and let's say this certificate is signed by this chain panda lucam as one of the the leaf certificates which we get so leaf certificate is the end certificate which cannot sign more certificates that's why I do not have CA at the end CA is the one which is the certificate authority which can sign more certificates if allowed by its signer so fandub lucam now whenever we have certificate certificate is the big container in a way and it has lot of attributes inside out of many attributes we have things like common name san and other aspects but two more things we have in a certificate is keys and we call them public key or private key now key pair of public and private is available in other protocols also for example SSH when we do SSH handshake there is also a public private key which gets exchanged but there is no certificate to exchange so the keys get directly exchanged in this case we the certificate exchanges that public key so I'm going to create public and private two names I am going to use there so I will say this pandaboy comm has a public and a private key so I am going to say P UB pub and T V T as private I'm intentionally using red and green colors because I will be using them for hashing encryption so it makes more sense now because we're doing SSL and we know SSL uses TCP I'm assuming the three-way handshake is already completed and I'm going to straight away start with the client hello so the first message between the client and the server would be your client hello message now in the client hello there are a lot of other information which gets exchanged but the most common or the most important message you are going to talk about is ciphers now cipher is a set of algorithms for encryption hashing and it's basically a suite and the client can decide to send how zyphus it wants to talk about so the client can say we support 16 ciphers so it's basically declaring that I as a browser or as an agent is capable of supporting sistine ciphers if the server wants to use any of those ciphers other informations apart from ciphers are like the TLS version we are using and a lot of other things I'm what we're trying to understand is the main concept which will make us understand the decryption or the fault proxy here so ciphers being sent to the server the server will choose one of the ciphers and reply back so it one selected cipher apart from the cipher the server needs to give a server certificate now the server certificate has two objectives the first objective is the certificate itself which is used to identify the server so that the client can trust the server if this is a at rustle destination I need to connect to the other objective of the server certificate is the the public key which goes inside the certificate so we're going to talk about both of them 1 another thing we need to understand is basically the certificate store which we have on the client a certificate store is basically a store where the client knows what are the trusted certificate authorities and certificates which the client can trust it could be a browser based it could be the operating system like Windows or Mac can have their own certificate stores the certificate store is important because this is what decides if the client can support trust the server and we typically expect either the root or the intermediate CAS to be part of the certificate store here so we can have a root CA or we can have the intermediate CA here if either of them are present on the client and when the server cert comes in the far other the client here understands that the Panda blue comm is a trusted certificate again not to go into the details I'm going to just take the certificates here and let's say we have panda blue dot com and this carries the public key inside so I'm emphasizing public key because that's what you are going to talk more about the public key which goes into this it does not carry private key ever the public key is the only key which is sent to the client the private key is never shared it remains on the server when the client receives this certificate and I'm also going to again do public here with the public key the next thing the client needs to do is create a shared secret key or I call it pre shared key or PSK so the client needs to first generate generate a PSK or like I said it's a pre shared key when the pre shared key is generated the public key which we received from the server is basically encrypting the PSK and then this PS key file is sent to the server so when the server receives the appreciate key which was encrypted by the public key sanba of its own it uses the private key to decrypt it and we basically get the appreciate key so this is one way of what we call it as symmetric and asymmetric keys so PSK here is the the symmetric key which was created through a symmetric keys so we use the asymmetry key of public and private to exchange the a symmetric key or a ppreciate key in this case so both the client and the server have the same key right now what they need to do is to generate a a master secret key but this key is basically calculated by both of them separately so let me use another color for that and I'm going to say calculate and I call it msk or master secret key also on some people also call it shared secret key or session key there are different names of session ID it's basically one final key or the ID which would be used to encrypt and decrypt between the client in future so let's do the same thing here where we use the PSK to calculate the msk or the master secret key by the way the PSK is not the only factor which is used to create the master secret key again not to go into the details but remember the ciphers which we exchanged those ciphers are also a factor to generate the master secret key so it's not just the PSK but the ciphers and there are other factors there are other random things which are used to make it more random so that it cannot be easily calculated by man-in-the-middle now that both the client and the server have this master secret key this key will technically be used to exchange any data between them so if I want to see if the client wants to send the data it is going to encrypt this data with the same master secret key I'm going to say encrypt here where the server receives this data the server can use the same key to decrypt it and then we can have the data here similarly when the soul needs to now send another data it can use the same master secret key send it over to the client and client can use the same master secret key to decrypt that data and this is why we call the master secret key or the like I said the shared secret key or the session key as the symmetric key we use the asymmetric key public and private we are the certificate to generate or calculate a master secret key which will be now used for encryption and decryption between the client and the server so now that we have a fair idea of how the SSL handshake works in terms of the key we use and the certificates now let's talk about decryption so why do we need decryption and I'm pretty sure most of the folks already are aware decryption is important because if the firewall cannot see what's going through the tunnel there is no way we can protect so it's basically like a secure tunnel to send threats through the firewalls so decryption is important again and we'll try to understand how can decryption work if it's so secure how are we doing decryption now the idea of decryption is to become a man-in-the-middle and we also call it a proxy a proxy term is used where the firewall or any device for that matter gets a packet and decides to create a new packet for that packet and that's when we call a proxy because I'm proxying for something so let's try to create a setup which I had there I might draw a little small now so let's say we have a client now now let's draw the server somewhere here and we're going to take the same example of pan double comm server and let's assume that we have the same hierarchy so I don't have to write it again soap and calm is signed by an intermediate CA which in turn is signed by a root CA now in this case you are assuming there is a firewall in between and let's say this is our one of our firewalls PA 220 I like it small M awesome power so we have a client we have a firewall and we have a server at the end now the firewall could be anywhere in the network and we'll talk about why the position of the firewall does matter when we do the decryption okay what we going to not talk about is when your own trusted network wants to go to the Internet then that's when we call it as foreign proxy because we already trust the firewall which is going to do proxy for us but we are trying to do proxy because firewall wants to protect for the contents which we receive from the server because we do not trust the server but we do trust the firewall in that situation we call it as foreign proxy or outbound decryption so in an outbound decryption again like we talked about there will be three-way handshake I'm going to skip the three-way handshake and we'll start the replay with client hello so let's assume the client is sending a client hello to the server again I'm going to now use abbreviated word CH because we have a little less space now and let's assume we have the same 16 ciphers being sent I'm going to skip the version and other stuff for now yes TLS version and everything else will also be shared with the server now when the firewall receives this package a client hello packet it needs to decide if it can decrypt and we do need a decryption policy which will check that our decryption policy lookup happens if we are familiar with the life of packet it's in the app ID stage where we do a decryption look up and the firewall realizes that this packet is either an application SSL or application SSH once the file will know that these are SSL and SSH only then it will go and check a decryption policy lookup so it says let me see if there is a decryption policy which wants the firewall to decrypt this traffic if there is the decryption policy which matches the firewall triggers the proxy mechanism and the proxy mechanism starts right from client hello so this client hello will now be stopped and a new client hello is created I'm intentionally using a different color to indicate it's a new packet now even though it might be a new client hello packet we are copying a lot of information from the client hello and we are sending it so let's say I'm sending the same 16 ciphers now a firewall may choose to reduce the ciphers which it sends that will be based on the decryption profile but we can talk about it at the end and we'll see what all we can do with the decryption profile so for now the firewall is rock scene a client hello with the same 16 ciphers so in a way if you see here the client here is the client and the server in a way here is a proxy server I'm going to write that term and if you see in this situation because the firewall is creating a new packet it becomes a proxy client and panda blue becomes the actual server here okay so we have a client we have a proxy server and the proxy client will actually talk to the server so when the server receives this packet what it sees is that the packet is coming from the firewall now the IP address or the layer 3 value of the client hello may change or may not change so let's not get confused when we are doing a proxy we are doing proxy at application layer the firewall may or may not change the layer 3 or layer for what I'm talking about is nothing if the firewall is at the edge of the network it may do the netting but that's not always the case so let's say now we receive the cypher same logic like we talked in the SSL handshake the firewall has to choose one of the best ciphers it wants to work on now because the client request came from the firewall the far the server is replying to the client or let me call it now proxy clients and in that server hello Sh it will select the one selected cipher again the server will also send its own version of TLS and other support information there and it will send the panda blue certificate in the panda blue certificate like we talked about it has common name and sand and other information it will also send the the public key as one of the attribute or one of the information inside the server certificate now when this certificate reaches the firewall the firewall needs to decide something and the decision is based on does the firewall trust the server certificate given by the server that decision can be made by the root certificate which is available in the certificate store so the firewall may have the root or the intermediate into the certificate store basically the file will also not trust like in the SSL handshake we have here the client has a certificate store where the client has to figure out does it trust the certificate from the server or not now because of this decision to make we need to create two certificates on the firewall which will in turn sign the new certificate we create remember we are doing a proxy so we need to create a new server certificate based on the original certificate because once the certificate is signed I cannot resign it with another CA so I need to create a new pandaboy certificate now this certificate will be signed by a so let's say we have our own root certificate here I will call it PA root CA and then this will have an intermediate which we'll call as trusted CA we need also another untrusted CA so I'm going to create another untrusted CA the reason why we need to see is is when the file will trust the certificate then it is going to use the trusted CA to generate a new certificate and sign it with that if the follower does not trust the server certificate then it's going to use the untrusted CA now remember we are not using the same certificate which we received from the server we are going to copy we are going to copy that information from the certificate like common name sand and all the other information and create a new certificate that's why I'm using a different color now and I'm going to call it panda blue dot-com and technically it should be a different public key so I'm going to use just red here oh sorry Brown not good with colors I guess so we have panda blue comm public key with brown inside that this certificate will now be shared with the client so when the server as a proxy server or our firewall acting like a proxy server is sending this it we'll send the server hello or a search in this case with one selected cipher with that cipher it will also send the chain of the certificates here I'm going to just write the last leave certificate just to save some space so let's say we have han the blue comm slash now so if you have panda blue comm with public key going with it remember this is not the same certificate it's a different certificate which was created based on copied information from the original server sort when this server certificate reaches the client now client has pan double comm with the public key okay and the firewall has Han double comm with the original key which we received and like we did before once the client receives the server certificate it has the public key and the client can now generate the PSK to be shared but remember if you're receiving pan W comm it is again a server certificate so don't you think the client should also have something to trust the authority so similar to what we had before the client should also have the root CA of your firewall now what if we do not have that if you do not have that the client would not be able to trust the certificate generated by the far wall okay this is why we need to make sure that on the clients PC if we have a third store here in this certificate store we need to have the the real root CA or PA see a on the certificate store of the client PC and this is important on every client PC otherwise the browser will give error as untrusted certificate now should we import the untrusted root CA also I don't think so not a good idea because then the client cannot differentiate what is trusted and what is not trusted the idea of creating two certificate authorities here for trusted and untrusted is to take the decision-making from the client of what is good or bad server to the firewall so when the firewall is sending a trusted root CA it means the firewall trusts with the client is automatically trusting it but if the file word does not believe this is an untrusted CA we can choose to still send the communication and let the decision be made by the client in that case client might be taking a risk because the farmer does not trust the certificate because we want the client to give an error we don't want the certificate authority to be imported if you import the untrusted certificate authority then the client would again start trusting the certificates signed by the untrusted CA here so the idea is not to do that and that's why we always need to create two separate trusted root CA and untrusted rules here okay so I just moved the untrusted CA here a little far away so that we don't get confused that this assignment is the arrows represents the signing here so not to confuse with that now we talked about the server certificate created by the server sent to the firewall the firewall creates a new server certificate or let's call it proxy server certificate and signs it with one of its own certificate authority depending on if the firewall through us the server certificate or not now that we have received that server certificate on the client PC the client PC can now generate a PSK and like before the client PC will use the public key it had before so the client PC generate the pre-shared key which needs to be sent to the server but it has to be first encrypted by the public key which will receive from the server so it will be encrypted by the server certificate remember the server certificate is not the original server certificate but from the firewall which we received as a client now this pre-shared key will now be sent to the firewall so let's say PSK and encrypted by the public when the firewall receives this PSK again because we are doing a proxy the firewall will stop this packet and trying to inspect this PSK so when this the firewall acting as a proxy server receives the the PSK packet it can decrypt this packet because it has the corresponding private key on the firewall because we created that server certificate and then we can now see the PSK which was again created by the client there the firewall acts as a proxy server but also a proxy client we are not the actual server so we need to send the PSK package to the server as well now we can create a new PS case so let's call it PS k - and this PS k - will be now shared with the original or the final destination and again we have received a certificate this handle comm with the green public key in a way was the original server certificate which the firewall received we are going to encrypt the PS k with that and then send this PS k to the original server here same logic when the server oh I forgot the - here when the server receives this PS k - which is encrypted by its own public key shared in the server hello it is going to now decrypt it so I'm going to use the same bread even though I'm using the same red color they are not the same private keys they're different we decrypt it and we then get the PS k2 here now we have a PS k1 available on the client we have a PS q1 available on the proxy server we have a PS k2 which is a let me write that here we have a PS q2 available on the firewall and a V we have a PS k2 available on the final server next thing we do is to calculate the master secret key like we did before so I'm going to use the PS k and other informations of ciphers to calculate the master secret key or the msk this master secret key remember like we discussed does not get exchanged it has to be calculated individually by both of them client and the server so I'm going to use purple for the msk calculated by the client and the proxy server and I'm going to use maroon color I believe and we are going to again calculate msk on the firewall and the server and let me again make this as msk to what you're trying to understand here is that the msk or the master secret key is not exchanged and calculated individually by the client and the server so now that we have the msk on the client and on the firewalls there are two immense case here and on the actual server what is the MS key used for if you remember what we did in the SSL handshake here we use the MS case to do the encryption and decryption now so this is the final key which will be used to do with encryption and decryption and that's what we're going to do so let's say this green is again data I don't have more colors so let's say we have a data we want to send here again because we want to send this data securely to the server so I'm going to encrypt this data okay so let's call it encryption encrypting it here so now let's say the client wants to send some data and let's say this data is the HTTP GET assuming it is a web traffic so we want to send some data then this data needs to be sent so let's use the same data here and we call it data and this data is being encrypted by the MS k1 which is this color when this data is received here the MS k1 which was calculated before can be again used to decrypt it so I'm going to decrypt this packet and get the actual data this data is important to the firewall because this will be used to figure out your categories to understand the applications which are going through the firewall in order to decide if we want to allow that packet to go through the firewall let's say the firewall wants to allow this data we are now going to use the MS k2 which was basically created between the far wall and the actual server so again there is a communication for that so we have data and this data is now encrypted by the VMs k2 when we receive the data here the actual server will use the msk to decrypt it and get the final data so if you see in a summary the data which was created by the client it went to the server through another encryption the server decrypts it reads the information encrypts it again with a new or a separate msk sense it encrypted and the final destination will receive this data and decrypt it with the msk to here and this in a way if you understand they're technically to SSL tunnels so let's talk about a data going through so the traffic goes through there is an encrypted channel here so this is technically everything let me use the same color to indicate that so this is technically encrypted here everything between the client and the firewall and there is another encryption which I'm going to use a different color here between the firewall and the actual server but in the middle session just is basically the clear text we have an encryption between the client and the firewall and we have under encryption between the firewall and the actual server but there is a clear text in the center this clear text will be the same data which we see here which is clear text because when the client is creating that data is clear text it gets encrypted gets decrypted then we have a clear text then it again gets encrypted then again gets decrypted and then we get the clear test here as well so the dotted lines was basically to represent that on the client on the firewall and on the server the data is clear text but everything in between is encrypted and there are two channels of encryption happening here for the for proxy cool learning to calm it well you're a great teacher so thank you thank you for watching this episode of learning happy hour at Palo Alto Networks we are strong advocates of continuous learning and we hope you are too to continue learning about our fantastic products and services you can attend a class with one of our authorized training centers or you can self-study about these products and services through our digital elearning courses and if you liked this episode of learning happy hour consider watching this one or this one and don't forget to like subscribe and share with your friends and thanks again for a while [Music]

Channel: Palo Alto Networks LIVEcommunity

Views: 8,642

Rating: 5 out of 5

Keywords: palo alto networks, ngfw, next-gen firewall, next-generation firewall, LHH, learning happy hour, panw, ssl, decryption, ssl proxy, ssl decryption, tls decryption

Id: 7LWRULh8z18

Length: 34min 33sec (2073 seconds)

Published: Tue Sep 03 2019