1. 7.1 Decryption concepts
In this video, we are covering Pcnsato 10, and this is our chapter on decryption and certificate management. Now this is the first video of Chapter Seven, which is 7.1 Decryption Concepts. Now why decrypt network traffic? Each year, more and more web traffic is encrypted. It’s really hard to actually find web traffic that is not encrypted these days. And attackers will use this encryption version to mask their behavior. Palo Alto Network Firewalls provide the capability to decrypt and inspect network traffic for visibility, control, and enforcement of security policies on decrypted traffic. Now, Palo Alto Networks’ firewall can decrypt SSH version 2 and SSL/TLS inbound and outbound network traffic.
If you do remember your OSI seven layers, we can see them on the right of the screen here. We can see this is our OSI layer, and we have a layer seven and a layer six, which are going to be your encrypted layers. And at layer seven, malicious content can be sent to the device, or that could happen at data acceleration, so those two layers are going to be encrypted while everything else is unencrypted. Layer 5432 and one they’re going to be unencrypted because the data has to actually got the end device or server. Now Firewall has to be able to decrypt the traffic to be able to identify what’s inside. If the firewall is not able to decrypt the traffic, it’s going to work blindly; it’s not going to know what’s inside. So of course attackers, they will use that method to excel trade data or use malicious content here.
Now for an SSLTLS session overview. The SSL/TLS protocol encrypts an HTTP connection between a client and a server where no preexisting secure channel is present. SSL/TLS is commonly referred to as just SSL. Imagine we have an internal user who’s trying to communicate with an external server through the SSL/TLS protocol to encrypt the HTTPS connection. An internal user will be sending requests over an SSL connection, and an external server will send its own server certificate. Now that’s called also known as public key. So a server does send this public key, and the public key always works. Now, a public key always works together with a private key. Now anything that we encrypt with a public key will be able to be decrypted with a private key. Anything that we encrypt with private, we can decrypt it with a public key and the internal user will take that public key and will verify making sure that actually that certificate has not been revoked, the date range is valid, the certificate issue in whoever issued a certificate like certificate authority is trusted issuer and so on.
Once he validates and makes sure that everything works fine, the client will actually generate his own symmetric key. Now for the communication and that key will be encrypted with a public key of external server. An external server will use a private key to decrypt it, and it will have a symmetric key, and then they will start communicating securely. Something called “perfect forward secrecy,” or PFS, occurs when communication partners periodically establish a new session and rehear the communication. Now PFS provides assurances that if private key has compromised for some reason and recorded former sessions cannot be decrypted. Firewall decryption types Now we have three types of firewall decryption type. The first firewall decryption type is called SSL forward proxy, and this is outbound. So if you remember an internal user trying to communicate with external server as securely using Https. Now an SSL forward proxy is where the firewall actually intercepts that communication, and it will generate one session here. It’s going to be one session on this side, and there’s going to be another session on this side. So on to session two.
So it’s going to be two sessions. So we’ll be able to actually decrypt the packets, check the packets for malicious content, and then forward them to an external server, usually making sure there’s no exfiltration of data. The second type of decryption that we have is called SSL inbound inspection and this time is when we have an external user is trying to communicate with our internal server, now usually using SSL, but this time the firewall is not a proxy. It’s not going to actually create two sessions, one with external server, one with internal sorry, external user, one with internal server.
The firewall this time, you remember that I told youth internal server has a private key, private key and public key which will be given, everybody has access to a public key, but the firewall has got the copy of this private key to itself. So it will be able to inspect any traffic that’s coming from the external user tour server it will be able to inspect. So it’s not going to generate a new session with an external user; it’s just going to be able to inspect any traffic that’s coming through to our server. And the third type of decryption that we have is called an SSH decryption, where the firewall is actually a proxy. It will create two sessions between the user and the server. Public key infrastructure, or PKI, does solve the problem of verifying the identity of the public key owner. So for example, if we go to Palo Alto Networks, we Palo Alto Networks issues us a certificate or public key using PKI, which we can verify.
Are they in for sure? Palo Alto Networks: A PKI digital certificate is a method of packaging and distributing public keys in such a way that proves the identity of the owners. Now. Palo Alto Networks firewalls They do support X.509 format certificates. For example, we have a root CA who’s going to issue certificates. For example, he’s going to issue a certificate for itself, and then it’s going to start issuing certificates for intermediate CAS. Intermediate CAS will issue a certificate for devices, and devices will have a certificate store in there. We’ll have trusted certificate authorities, certificates, and private keys. So, for example, consider the certificate chain of trust. If we get a certificate, for example, and say that we receive a certificate from this device because we trust this intermediate device and root CA and everything is fine and valid, then we believe that these are who they say they are. certificate authority. An example certificate for this certificate we have is Go Daddy root certificate authority, and we can see that that certificate has been issued by itself.
So Go Daddy issued a root certificate to itself, and we can see the date; the valid date ranges from there to 2009 to 2038. We have three tabs here. This is your general tab; we have a detailed tab. So if we press that, we’ll get this detailed information about that certificate, i.e., The version, the serial number, the signature, algorithm, hashing signature issuer, valid range, subject, and the public key And then, if we look at the certification path, we can see who issued that certificate. But since it’s issued to itself only, then there’s only one on the path. If you look at another certificate, and this is just the device certificate, for example, we have a look at the Go Daddy web certificate that has been issued by the Go Daddy certificate authority, and you can see the range. And if we look at the detail, it’s going to be similar to what we saw earlier, a certification path. We can see that this certificate has been issued by intermediate CA, and intermediate CA has been issued by CA.
We can click on each one and find out, and we can view the information. The firewall features used in the certificate now Palo Alto Networks Firewall uses certificates for many purposes, for example Salts decryption management, interface user authentication, global protect like portal authentication, gateway authentication, mobile security manager authentication, about which we’re going to be talking a lot more in Chapter Ten, capital portal user authentication, IPsec VPN authentication, and IKE authentication. Again chapter ten, a lot more about that and chapter eleven, high availability authentication as well as secure syslog authentication which is chapter eleven certification and revocation check in. Now sometimes a certificate needs to be revoked, and these are some of the reasons why we revoke certificates. For example, private key has been compromised, hostname or user name of owner has changed, host retired or user has left the company, counterfeit key has been found.
So now that we look at the chain of trust, we look at all the certificates, and we cannot validate each certificate in the chain. So, like we said earlier, this is your chain of trust. So we validate this, we validate this, and we validate this, making sure the signature is valid, the date range is valid, and there is no malformed or corrupt certificate. Check each certification’s revocation status, making sure the certificate has not been revoked. And we have two methods to do that. We can do it through the certification revocation list, where we can download all the certificates that have been revoked. The certificate authorities are required to keep a list of all certificates that have been revoked. And the second method is to use the online certificate status protocol.
Now this has replaced the use of CRLs because you don’t want to download a potentially very large list of all the certificates that have been revoked. Instead, you could just ask with the online certificate status protocol, “Check the serial number of the certificate. Has it been revoked or not?” Certificate signing Request now messages are sent to certificate authority to acquire certificate. If you want a certificate, for example, for yourself, you need to generate a public and private key first. You don’t send the private key, but you do send all the information, encrypt it with your private key, and send the public key to the certificate authority. So the certificate authority will be able to decrypt with your own public key. And once it’s fine, the certificate authority will encrypt everything with its own private key and send it to you. which means that you can decrypt it with a server’s public key.
Okay, I just want to draw this to make sure we understand that we have a public key here. Public key, this visible public key for the Canada the CA has got its own private key. Now that the private key is secret, nobody should be able to see it. And this device, for example, will generate a public and private key, will use its own private key, and will assign and encrypt the identity information like everything: who is it, where is it from, address, and so on. And it will send and it will send it will encrypt it with the private key and it will send it to the server with its own public key. So the server will be able to decrypt it. So once everything is fine and the server is happy, it’s going to encrypt the information with its own private key and send it to the user or to the device. And the device will use a public key to decrypt everything. So just one key encrypts it, and the other key decrypts it. So advantages now the device will be a part folk or public key infrastructure and benefactor of chain of trust and private key never leaves the device.
2. 7.2 Certificate management
And then certificates in there we have certificate profile, an OCSP responder, and so on. We cannot touch on all of these in the next video. But first, just certificates. As you can see, there are no certificates by default. And we’re going to create—actually, we’re going to create four certificates. Four certificates. The first certificate we’re going to create is going to be a self-signed certificate. Self signed. And this certificate is going to be the CA, which means it’s going to be a certificate authority, and it’s going to be able to sign other certificates. Now this is going to be our root certificate. So we’re going to take this certificate and we’re going to send it to all the client machines in our network and we’re going to import it in there. So export it to us and then import it to their client machine so they will trust it because, by default, nobody is going to trust a self-signed certificate. And then for every certificate that this certificate signs, these devices will trust it by default.
The second certificate that we’ll create is going to be a forwarding CA, and this is a forwarding trust CA. So let me just write it here. It’s going to be trust, which means that if the devices go to somewhere that we trust, we’re going to decrypt obviously the traffic and we’re going to say, yes, it’s fine, you can go there. So it’s a trusted place. And this is going to be like in hierarchy. So this is going to be signed by this certificate, so we don’t need to export it and import it on these devices. And the third certificate we’re going to create is for management, so we can actually issue a certificate for managing our firewall, and this is going to be signed not by the second one, but by the first self-signed certificate, even though the second one can sign it as well. And then the fourth certificate that we’re going to create is “forward entrust,” and this certificate is not going to be signed by anything, and we’re not going to be exporting or importing it anywhere. So if the device is to access some website that we don’t trust, we can forward this certificate and say, “Hold on, this is an untrusted place.” Okay, let’s do that. So let’s create our four certificates, which I can show you or generate the certificate.
If I click on this “generate and certificate type,” we have two options. We can have a local or skep, which is a simple certificate enrollment protocol. Now, this is outside our course curriculum and so on, but it’s a draft, and it simplifies the way we hand out certificates for something that is not for this course anyway. We’re going to create a local certificate, and the common name we’re going to give it is “Self-signed Certificate Authority.” It’s going to be a self-signed certificate from the CA certificate authority, which will be able to sign up the certificate’s common name. Now we can put there, we can put any address, we can put a fully qualified domain name or the purpose of the certificate.
We can just put text in that on this. We’re going to see it. 1921-6811, the IP address, and signed by us for an external authority certificate signing request. Or we can leave it empty and just say “certificate authority,” which means it’s going to sell. Sign it using the OCSP, or online certificate status protocol, to check. Has this certificate been revoked? For example, if you want to put it there, we can have empty cryptographic settings, change the algorithm number of bits, for example, and digest. I’m just going to leave it empty, and we can have how many days this certificate expires now because this is going to be like a root certificate authority for our organization. I would put more than a year here. I would put it on for like ten years and then take this device or this certificate and hide it somewhere. Anyway, for us, we’re just going to leave it at default 365, which is one year. Certificate Attributes I’m going to leave this blank; you can put things like country, state, locality, and so on. For alternative email, I’m going to leave it empty and then just generate, and you can see now that it says successfully generated the certificate key pair, which is the private and public key of that certificate. And here we can see the validity, the expiration date, and the name of the certificate. Now if I want to change something or edit this certificate, I can just click on it and you can see the name. There some stuff that we can’t edit and then we can say forward trust, forward entrust certificate or trusted root CA.
So I’m going to click that and click OK; that’s our root certificate. Then I’m going to export this certificate, and then on the next video, I’m going to import it on our enterprise devices so they can trust it because, by default, nobody’s going to trust this certificate because it’s self-signed. So export the certificate, and we can export it in three different file formats, so we can export it in base 64 and code a certificate, we can import and export it as a binary encoded certificate, or we can visit the private key on PKS 12. I’m just going to leave it at base64 and not export the private key. Click OK; now it’s already exported here, so if I click on it and then select Open, I can see my certificate, and by default, you can see the certificate is not trusted. Already the computer is telling us that this certificate root certificate is not trusted issue to this IPad dress issued by the same IP address and then you can see the valid date range as well as we can see for example details like version, serial number and signature algorithm and so on.
This will go through the first video, and we can see the certification path and click OK. Now I’m going to create one more certificate for the forward trust certificate, which is going to be signed by this. So I’m going to generate another certificate, again local, and I’m going to say forward trust certificate authority because this will be signing the certificate as well. can signal a certificate, and I’m going to use it, and the common name is just that, and this is going to be signed by a self-signed certificate because this certificate will be copied to the clients. The clients believe they can trust that certificate, and then they will trust every other certificate that has been signed by this certificate, which is going to be our certificate authority as well, and click generate. Now you can see that it has generated a key pair for this certificate as well, and you can see that it’s in the hierarchy list. So it’s like right away I know that this forward trust certificate has been signed by self signed certificate so it’s easy to visualize what certificate is being signed by what certificate and just to edit this.
So I’m going to click on it, and I’m going to send it a forward trust certificate. So when the client accesses some trusted place, we’re going to send them this certificate, and I’m going to generate another certificate, and this time it’s going to be a forward entrust certificate, and this is going to be a signing certificate as well. It will be able to sign up a certificate so certificate authority but I’m going to say not sign by anything, not going to sign by forward trust or self signed certificate.
I’m just going to do empty and generate that, and then you can see in the hierarchy that it’s like a different one; it’s not underneath the self-signed. And the fourth certificate I’ve said is going to be the management certificate. so much search. And for this, I’m going to use the IP address of the management IP address, which is one nine: 2192-168-1254. And this certificate will be signed by a self-signed certificate. This is not going to be signing certificates, and it’s not going to be able to sign any other certificates. And just click it to generate the management certificate you see here. I consented. It’s not a certificate authority. It’s not consent. Trusted, untrusted, or root CAs can be used for certificates for secure syslog, or in our case, they’re going to be used for management purposes. Okay, we’re going to leave it at that, and then we’re going to continue with the next video. Do when we’re going to import it to our client machines.
3 SSL forward proxy decryption
In this video, we are covering PCNSA 210, which is our chapter on decryption and certificate management. Now this is the third video of Chapter Seven, which is 7.3 SSL forward proxy decryption. Now, forward proxy decryption, if you can imagine, is also called SSL forward proxy outbound. Now imagine the internal user trying to communicate with the external server. Now, internal users will request an SSL connection with an external server. An external server should send a certificate.
But if we have SSL forward proxy, what this means is the firewall will actually intercept those packets, will decrypt them, make sure that everything is fine, not some sort of exfiltration traffic happening or anything. And then the firewall will in turn request Ansel connection for internal user behalf and the server will send the certificate to the firewall. Firewall again, because it’s got its own request, so SSL will be able to read that information, and if everything is fine, the firewall will sign the certificate with its own forward certificate or forward trust certificate. And there will be two sessions. So by default, we have two sessions on the SSL forward proxy. We have a session between the internal user and the firewall, which is session key one, and then between the firewall and an external user, which is session key two. The validity date of the firewall certificate is taken from the validity date of the destination server certificate. The firewall acts as a proxy for the SSL connection, not the underlying traffic. And if you use the packet capture functionality, it executes before decryption.
So any package that you have captured will be encrypted. Now forward trust and forward entrust certificate. Once a user requests an SSL connection to the server, the firewall will intercept it and generate a new request connection. The server will forward its own certificate. If that certificate is trusted, the firewall will send a trusted certificate to the user. So forward trust certificate, if that certificate for some reason is untrusted, the firewall will send its own untrusted certificate. So if this happens, then the user will see that as a “blocked page warning” and they will get to see that, okay, well, this is not trusted by the firewall, which is acting as the proxy, but the user can actually go forward, can proceed, and just advance it’s. Fine, they can go forward if they want to. Okay. Now I’m going to show you the firewall. What we did on the second video, where we actually did create these four certificates, And this certificate, a self-signed certificate, is its soured certificate authority or roots certificate authority.
And this certificate, we’re going to actually export it, which we did on the last video, but I’m going to do it again. We’re going to export it from here and then we’re going to import it in our client machine, which is our Windows seven PC here inside. And then we’re going to create our SSL forward proxy and we’re going to check it right so that’s the idea. So if I go back to my firewall, I’m going to take this certificate and export it. So I don’t need to export the private key. I’m just going to export the public key and then import it on our client machine. So click OK. And this is already exported. So I’m going to go to my PCA, which has a folder that is a shared folder with my physical machine, which is under the folder “network host shared folder.” Downloads are here. So I’m going to take this certificate—this is the one that we just exported—and I’m going to import it here. Okay, that’s not done; that’s not important yet. So I’m going to open the certificate management on the PC, which is here already. But I’m going to show you from the beginning. So you need to click Start, and then in there, just type MMC.
So Microsoft Management Console, open that, and in that console, I’m going to add a snap-in for certificates, and when I click Add, I’ll have to choose whether the snap-in will always manage certificates for my users’ service accounts or computer accounts. Well, this is going to be for Computer Accounts and click Next local Computer or another computer while it’s going to be for local computer. And that’s it; that’s how we get to the certificate management for this local machine. Okay, so if I open it, I have a personal certificate here with nothing at the moment, and I have trusted root certificate authorities. So by default that certificate, these are automatically published, populated here’s, for example, if you go to your website, they will check if it’s been signed by one of these. We trust already these roots CAS and in here I’m going to import the self signed certificate from our Firewall. So I’m just going to right-click all tasks and then import them by clicking Next. And the certificate is already on the desktop because I copied it there, and then that’s my certificate. and click open. See it’s x 509 and next place all certificates in following store. Yes, and finish.
So what is happening in the moment is importing that certificate, a self-signed certificate. So any certificate that’s that route orca signs that will be accepted. Okay, so that’s the certificate that we just imported. Okay, great. Now I’m going to go to my firewall and create an SSL forward proxy, which means that any traffic that has SSL traffic will be able to be decrypted by this firewall, right? So to do that, I need to go to policies, and then under the policies, I need to go to decryption. And here I’m going to create a forward or SSL forward proxy. Now, just to say that not all the traffic should be decrypted, Some traffic cannot legally be decrypted. For example, depends on the local law and regulation concern like health records, financial records and other privacy concern, which you shouldn’t be able to delete them or decrypt them, I should say. Okay, so here we’re going to create a new SSL forward proxy. So I click “add” and in there I’m going to say “decrypt URLs,” which is going to decrypt all URLs, and then we would write the description tags and so on and comment source. Well it’s going to be from inside, so inside zone. Source address.
Well, it can be our network. I can put the IP address of our network, which is 1921-681-0424, and source user, but we don’t have a user ID, so we can leave that and destination, while destination is going to be outside, so outside network, any destination address, services, or URL. Well, it’s going to be any URL, any services, and any options. Now under the options, I have the option to not decrypt that traffic or decrypt that traffic. And as you can see, we have three types of decryption. We can have an SSL forward proxy and SSL inbound inspection. That means like any traffic coming from outside to our inbound service. Or it can be an SSH proxy. Well, this is going to be an SSL forward proxy and decryption profile. I’m going to leave it none, but we’re going to come back, we’re going to create a decryption profile and we come back and populate this click, okay. And let’s do that. Now create that decryption profile so we can see it here.
Okay, to create that decryption profile, we need to go to objects, and towards the end, we have a decryption profile. So we need a decryption profile, and already we have one predefined, but I’m just going to create my own one. So I’m going to say a strict decryption profile. And in here, I’m going to see the SSL forward proxy. For example, I’m going to block sessions with expired certificates. I’m just going to take all of them right, very strict and for example, not decryption well, block session with expired certificates, block session with untrusted issuers. This is an SSL description. So forward proxy, it’s going to populate that. We have an inbound inspection and SSL protocol settings.
Okay, click that, then click okay. And then I’ll go back to my encryption policy and add that decryption profile. So option and decryption profile, output mine and click okay, now we’re ready, we set. So I’m just going to click commit, and then we’ll go and check it. Okay, this commit has been successfully completed. It just says the forward-entrust certificate is not configured. I thought I did that on the second video. So let’s go check it out. Okay, there and go to device and then certificates and thought I did this, so I’m just going to click there, I forgot here to click forward entrust certificate and then I click okay and commit it again. Okay, now the committee has been completed successfully. We can go and test it. If I go to monitor, I see traffic and everything that has been decrypted. It’s going to be added here. So by default, this tab is not there. So I have added it, so you can see that it’s been ticked by default.
On the monitor, you can see something like this. So if you want to see the packets that have been decrypted, you just click on any downward-pointing arrow, and in the column, we just click “decrypted,” and we can see if the traffic has been decrypted. So I’m going to go to my client machine. Okay, so to test it, to test in our client machine, I’m going to go to that antimalware test file and we’re going to try and then download and we’re going to try and download the encrypted version. Yeah. So https 2016 acorn.org okay, so if I click on download antimalware test file and you can see still the clear text is not provided at the moment. I’m going to try to download one of these. But these are our SSL so click on it and as youkan see, it’s already telling us if we didn’t have decryption.
I already can tell it’s been decrypted and it’s found out there’s a virus and it’s blocking it.If we didn’t have a decryption, it wouldn’t be able to find it; it would be able to just download it. So we can try it again. Try to download the next one. You can see that all of them are being blocked. Right? So I’m going to go to my firewall and go to Monitor and have a look. Just update this, and you can see that all of these have been decrypted. All of this traffic information I can go to Threat as well. And you can see that he has found some virus-detected virus in there, and this has been decrypted already. I can click, you see, because there is packet capture that’s going to be in encrypted format. But if I open this just by clicking on the magnifying glass, we can see more information on this packet capture, and if I go further down, we can see that it has been decrypted. We go through packet capture, and it’s been reset from server to client. Right? So already we can see that the decryption policy is working for us. And close this. Okay, so that’s it. For this video, we can actually go to the next video. We can look at the end.
