PCNSE: Palo Alto Networks Certified Network Security Engineer Certification Video Training Course

PCNSE: Palo Alto Networks Certified Network Security Engineer certification video training course by prepaway along with practice test questions and answers, study guide and exam dumps provides the ultimate training package to help you pass.

SSL Decryption

1. Certificates, Certificate of Autorities, and Decryption Concepts

In this lecture, we will talk about decryption concepts. As we start, we're going to talk about foundational topics and understand what the difference is between symmetric and asymmetric keys. So symmetric keys, encryption Both sides of the conversation have the same key to encrypt and decrypt the traffic in isymmetric encryption. There are two keys. One key is called the private key, and the other key is called the public key.

The private key is private to one side of the conversation, it's not shared with anybody else, it's secured, and it's a problem if it gets leaked out. The public key is basically handed out to anybody who wants to talk to that server or system. The public key is used by people to communicate with the holder of the private key. And then the private key holder encrypts something with their private key and sends it to its destination. The destination would decrypt it with their public key. The other side would encrypt with the public key and send it to the server, and the server would decrypt with its private key. However, there has to be some sort of validation process, and the validation process is called certificates.

So the certificate is basically the public key, and the public key is signed by a trusted party. This trusted party is called a "certificate of authority." The certificate of authority takes the public key and then signs it after validating the person's or system's identity. To get your certificate, for example, if you [email protected], you would send it to a certificate authority like Versesign, and Versesign would ask that person or company, "Prove your identity, proof that you are this person, proof that you own the domain." When you prove that information to them, what happens is a certificate of authority.

A certificate of authority also has a private and a public key. The private key is kept on the same machine as the certificate of authority. It is not shared by anyone else. A certificate of authority would sign the public key of the requester, which in this case is Yahoo, which would basically sign that certificate of authority using its own private key. And then it does the hashing function. The hashing function produces a mathematical operation on the public key, and then it produces a fixed number of bytes, a fixed number of characters that is considered the hash. Thexis hash. and then it will encrypt it with its own private key. After encrypting it with its own private key, it will send it to the register. And the requester now has a certificate.

A certificate. You can also think of it as a driver's licence that you can show to anyone who wants to verify your identity. So, to recap the certificate of authority, after validating the requester's identity, it will issue them a certificate. The certificate is composed of a hash of the requester's public key encrypted by the certificate of authority's private key. This is considered the certificate. The certificate consists of the public key of the register, information about the certificate of authority, and then the signature of the certificate of authority.

So, now that the certificate has been issued to the requester and installed on the system or server, anyone who connects to that server and attempts to do encryption will be presented with a warning. The certificate that the browser would connect to at [email protected] will be presented to the browser. The browser checks to see who signed that certificate. It checks to see the certificate of authority and the information about the certificate of authority. The certificate of authority is trusted, and browsers have a trust list of certificates of authority, and systems like Windows, Linux, and Mac have a list of trusted certificates of authority. They will check and see if one of those people signed that certificate.

If it did, it will validate that the certificate of authority actually signed a certificate. So it looks at the certificate of the server, gets the public key from that certificate, and then does the hashing algorithm that's specified in the certificate and gets the hash value. Okay, that's a value, and then what it does is it decrypts what the browser would do, which is the browser would decrypt the signature that's in a certificate, and the signature was the signature of the certificate of authority using the public key. Remember that the certificate of authority signed the certificate or encrypted it using its own private key.

The public key of the certificate of authority is available in the system as a trusted certificate. So it will go ahead and decrypt that signature with the public key of the certificate of authority, the value b. Now it's going to check the certificate and the public key of that system at @yahoo.com, and it will hash that public key using the same hash function used by the certificate of authority, and then it's going to produce value b. If values a and b are equal, that means the certificate was really issued by that certificate of authority. So now it can continue communicating with that server.

When the certificates are issued, they are not necessarily issued by one CA. There could be a chain of CAS that issues certificates. The CAS chain is made up of the root CA, which is at the top of the certificate authority chain, intermediate CAS, and possibly issuing CAS. So we can have multiple levels of certificates of authority. It looks to see if the issuer of the certificate is the root or not. And if it's not the root, it's going to go ahead and check the root CA certificate that's in the certificate chain of the certificate presented by the server. It's going to do the hash function of the public key of the root CA.

This is one value, and it's going to decrypt the digital signature of the root CA using the public key of the root server in that case. Then the roots would be checked out. Then it's going to check the intermediate, and it's going to do the same thing now: decrypt the intermediate certificate using the root certificate, a public key. And that's where it's called "path validation." It checks from the top down all the way through the issuing CA. But we're going through this and explaining two levels. It will obtain the intermediate CA certificate, and the digital signature will be decrypted using the root CA's public key. It gets the hash, and then it's going to do the same thing by looking at the public key and then hashing it using the same hash function to see if the two match.

So if it decrypts it using the root CA public key and it matches its own hash function, then it checks out. Then it's going to look at that server certificate, [email protected]; it's going to look at the end of the chain, the actual certificate that was presented, and it's going to do the hash function on that certificate. And then it's going to decrypt the digest or the signature of the signature in that certificate using the issuer now, because the issuer is the one who issued the certificate, and it's going to check and see if the hash value matches the decrypted signature.

And if it does, that means both hash values match. That means the certificate is validated. It's not validated all the way up to the roots here. So that's the certificate path for addition. When you look at the certificate of any domain, for example, this [email protected], you can see the certificate hierarchy. That's what I was explaining. You have the root CA, the public primary certification of authority, and then you have the immediacy and are immediately issued a certificate.

The browser actually checks from the root to the immediate rather than the server's certificate. The hashing is then useful for the signature. It's looking at the signature value here. That's what it needs to decrypt using the public key of the certificate of authority. And then it knows how to decrypt it by looking at the certificate signature algorithm. In this case, the certificate was hashed using the SHA-56 hashing function and then encrypted using RSA. That's how it knows what hashing function to use.

SSL uses the certificate system to validate the server certificate. What happens is that when the SSL client connects to the server, the server would send a certificate, and then the client would send the cypher suite, or what cyphers are acceptable to be used for encryption when communicating with that server. The client will then send a secret key encrypted with the information from the server's public key. It's going to say, "Okay, if you are that certificateholder, I'm going to use a random value and hash it with your public key and send it over to the server."

The server now should be able to decrypt that value because it's the only one that has the private key. After that point, they're going to finish the negotiation, and then they're going to start exchanging encrypted messages using a shared secret key that they agree upon. This diagram shows us how client-server communication happens. Clientele messages are sent to the server, and then they contain the TLS version number or SSL version number, a random number.

The server should be able to decrypt the suggested cypher suite and compression method. The server would send back the TLS protocol version that was selected, the random number, and the cypher suite. And then it's going to send the certificate, and then it's going to say, "Okay, I'm done." Now the client will validate the certificate.

Once that master key was determined between the two, then they were going to start decrypting, encrypting, and decrypting traffic. When the master key is selected, the master key is used to do bulk encryption. So the asymmetric key functions are used primarily to negotiate the certificate, validate the identity of the server, and also negotiate the master key. Right? And once the master key is selected, then from that point on, the encryption will be symmetric. And that's the point that I want to make: the first stages are symmetric in the SSL conversation.

The other stages are symmetric with SSL encryption. Do you put the firewall between the two conversations and tell it, "Hey, you're going to do SSL proxy?" When you configure an SSL proxy, the client attempts to connect to your server via the Internet, either internally or externally. The actual firewall would look at the server certificate, and then it would issue its own version of that certificate. It acts as a certificate authority by itself. Right.

The SSL proxy function relies on a certificate of authority, which is configured on the firewall. It will rewrite the certificate in a way to take the information from the public key and then sign it with its own CA information. So when I sign it for this CA information, it will send it on to the client. It's going to proxy the connection. The first client is going to try to get to the server. The server will be reached, and a certificate will be sent down. The firewall proxy engine would rewrite the certificate and then send it to the user.

And then the user would decrypt the message using the CA certificate on the firewall. And then it's going to say, "Okay, this checks out," and it's going to go back and communicate with the server about the master key used for the symmetric encryption. And at that point, the firewall is seeing all that traffic, and it's able to decipher it and figure out what's going to be a symmetric encryption key used in a conversation, and it's going to be able to decrypt that traffic and analyse it for threats and viruses, data filtering, and others. And this is another diagram.

Client communication requests, such as @yahoo.com Firewall proxies that initiate the session to @yahoo.com request the certificate. Once it gets a certificate, it's going to create a copy of the certificate using its own internal CA and send it to the client. Okay? Now the client will go ahead and validate that certificate using the Firewall CA certificate, and it will do the key exchange and negotiate the symmetry key or the master key for the encryption.

Within this process, the firewall understands the communication going across because it's actually the one who sent its own certificate to the client to validate the decryption that's going across. Now the encryption and decryption that's going across the channel is understood by the firewall, and that's how it puts itself in the middle of the conversation and understands the traffic and does all the threats and content verification, application identification, and other functions. So there are two types of certificates that you can configure on the PaloAlto Firewall SSL: trust and untrust.

So when you connect to the Internet, sometimes you will have some sites that will give you a warning saying, "Hey, this site is not trusted." if the firewall proxies all the certificates without letting the user know. Because now that the certificate of authority function is configured on the firewall, it gets any certificate from the internet and is going to present that version to the user. If the user trusts the CA certificate of the firewall, any certificate, trusted or untrusted, will be accepted by the client. We want to pass the information on to the client to let them know that this certificate is not trusted. And you do this by configuring two certificates on the firewall, one trusted by the client and one not trusted by the client. The firewall is then configured to forward trusted certificates from trusted CA to the client and untrusted certificates from servers elsewhere using untrusted CA.

This way, when the client gets the version of the certificate issued by the firewall, it knows that this is trusted and this is untrusted. Inbound inspection is a different story. Inbound inspection occurs when your firewall listens for connections coming into your systems. And those systems are configured for SSL, and they have certificates. So in order for the firewall to understand the traffic, it will need to know the certificate on that server. In order for it to be able to decrypt the traffic, it needs to get the private key so that it can listen in on the conversation and understand what's going on. To get the private key for that firewall, you need to export the certificate from your internal servers and import it into the firewall. and we're going to see this in the lab. How to do this SSL excludes inspection. Sometimes you have systems that you don't want to decrypt traffic for.

On the back end, HR, for example, may communicate with ADP. You don't want this traffic to be decrypted because it's carrying sensitive information about employees, including salaries and Social Security numbers. And then you don't want the firewall administrator to be able to see this information. So you can configure the firewall to not decrypt some SSL certificates. And this is advisable for trusted communication between trusted parties, like, for example, your partner's EDP and HR. ADP and HR servers can communicate. Most systems are trusted. The communication is not vulnerable to eavesdropping by a third party. As a result, it is safe to pass this traffic without performing the SSL inspection. That covers SSL decryption. And SSH decryption is pretty much the same thing. In the following lectures, we'll look at how to do the configuration.

2. SSL Forward Proxy - Trust Certificate - Local Cert on Palo Alto

And we need to close the browser and open it back up again. And now it doesn't complain. If we click here to see the details of that certificate, we will see that this certificate is issued by www.google.com, issued by, and verified by, 172-3112. There is no issue. Now it's going to go ahead and accept the certificate and proxy it. This is how you do the SSL proxy for the client to the firewall, to proxy the traffic for the clients and basically be in the middle of the traffic and look at vulnerabilities and attacks and other things that exist in the encrypted traffic.

3. SSL Forward Proxy - Untrust Certificate - Local Cert on PaloAlto

Now that we've created an SSL forward proxy and trusted it on the clients, we want to make sure they understand that whenever a certificate isn't trusted, we don't want to proxy it with the same certificate that we're proxying with the trusted certificates.

So, in order to accomplish this, we will navigate to device certificates and then specify to create or generate one. And we're going to generate certificates here—internally, we'll call this certificate of authority—and we're going to give it an IP address as a common name and generate that. We're just going to call it internal for now.

To distinguish this, we'll click on that certificate and specify to forward an untrusted certificate, then click OK. OK, we're going to go to our policy description, and since I'm using an internal IP address, I'm going to specify any categories. This is where we proxy anything. Then click commit, then click Okay, I'm going to try to access a website that doesn't have a trusted certificate, and we will see what shows up here. Untrusted connection.

We want to see what this certificate basically says. I'm going to specify to understand risk and add an exception, and then I'm going to add this exception. issuer status: untrusted certificate error. There is an issue with the SSL certificate trying to connect. So it's untrusted. So it blocked it because we had in our previous lecture specified to block those. So I am going to go back to the object decryption profile and uncheck those things. Block the session with an expired certificate and block I'm going to uncheck "Block sessions with an untrusted issuer" and commit to not blocking it this way. So we'll see. When you blocked it, you got a message that, "Hey, this is not an acceptable certificate; you can't go there now." I'm going to try again.

Okay, if I look at this certificate now, more information This certificate was proxied using the certificate that I just created and specified that this is to proxy only untrusted connections, right? So if I go back to the certificate here, I have two certificates, one for proxy trusted certificates and one for proxy untrusted certificates. So I'm still proxifying that traffic, but I'm relaying to the user that this certificate is not trusted. So I'm going to go ahead and delete that exception. This certificate, you see, was proxied by the certificate that we have in the firewall's panel to proxy untrusted. But I want to show you guys that the client still gets Hey, this is not an acceptable certificate. We can do it from another browser.

Okay. Try to go. As you can see, there's a problem with this site. You want to continue at your own risk. You click "continue," and the certificate now has errors, though we can still see that it's internal. So the catch here is that you need to have two certificates, one to relay the trusted certificates and one to relay the untrusted certificates. For the one that's going to relay the trusted certificates, you need to have the client have this as part of our trusted CAS in their browser configuration, and one that is not. You don't want the user to have this as part of their trust certificate. This way, anytime they get to a website that has an untrusted certificate, they will get the message that this is untrusted.

So to recap what we did here, we created another CA and checked here to forward an untrusted certificate. That's basically all we did, right? And on the client itself, we did not add this as a certificate of authorities that is trusted. So anytime the user gets to a website that has an untrusted certificate, they will get the message, and they will proceed at their own risk. We had to go back in our decryption profile and uncheck block sessions with untrusted issuers. When this was checked, they got a block message saying, "Hey, this is not an acceptable certificate." You cannot go there. I'm still specifying the block session with an expired certificate. So I want to make certain that you understand the distinction between Ford trust and Ford trust us.

Prepaway's PCNSE: Palo Alto Networks Certified Network Security Engineer video training course for passing certification exams is the only solution which you need.