whitepaper HP Jetdirect and SSL/TLS June 2008 Table of Contents: Introduction ..................................................................................................................................... 1 What is SSL/TLS? ............................................................................................................................ 2 HTTPS Decoded ...............................................................................................................................
correctly. One of the purposes of this whitepaper is to show administrators how to properly deploy SSL/TLS so that it can be used securely. SSL/TLS is also used in other applications, such as LDAPS and 802.1X. This whitepaper will discuss how SSL/TLS works when Jetdirect is operating as a client (e.g., LDAPS, IPPS). 802.1X is covered extensively in a separate whitepaper. See http://www.hp.com/go/secureprinting for the latest information regarding HP’s printing and imaging products.
see that SSL/TLS requires application changes in order to be utilized. These changes have to be made by every application that wishes to utilize SSL/TLS. In other words, SSL/TLS is not application transparent. Web Browser HTTP:// Web Browser Application Code API: Socket(…) TCP IP Web Browser HTTPS:// Web Browser Application Code API: SSLSocket(…) SSL/TLS TCP IP Figure 3 - Application Changes Now, let’s have a closer look at HTTPS.
Figure 4 - HTTP Session The URL starts with http:// and tells the browser that SSL/TLS is not required. Let’s change it to https:// and hit the [Enter] key. We are now presented with the dialog in Figure 5. Figure 5 - Secure Connection Clicking “More Info”, we get the dialog in Figure 6.
Figure 6 - More Info Notice the sentence: “This Web site provides secure communication and has a valid certificate.” After reading this whitepaper, you’ll know whether that sentence is correct or not. Now that we have read the “More Info” text, let’s go back to the dialog in Figure 5 and click “OK”. Now we get a security alert dialog shown in Figure 7.
Well, we’ve got one green checkmark and two yellow warnings. Good enough for us! Let’s click “Yes” and establish the HTTPS session with the MFP. Figure 8 - HTTPS Session We have now “secured” our web browser session with the HP MFP. How can we tell? Well, we can look at the URL and see https://, but we can also look at the bottom right of Figure 9 – Lock Icon.
Figure 9 - Lock Icon The mouse pointer was placed on the lock icon. Notice the “SSL Secured (128 bit)” shown in the bottom right. If we double-click on the lock icon, we get a dialog box similar to the one in Figure 10 – Certificate Details.
Figure 10 - Certificate Details Something is very wrong here. We went from yellow warning symbols and green checkmark to a big red X symbol. We have a 128 bit SSL secured session with the HP MFP but we now have a big red X indicating a trust problem. This problem is best explained through an example. Let’s assume that you are a famous celebrity and that you are having an electrical contractor work on your mansion.
Digital Certificates Much like a fake ATM machine, an unethical hacker could use technology to direct a user to a false web site when they are thinking they are going to a trusted website, even if they are using SSL. When typing in https://, Internet Explorer 6 (IE6) will pop-up a dialog when it encounters a digital certificate that it doesn’t trust (i.e.
Figure 12 - IE7 Certificate Error 1 This screen is a lot different from IE6 – notice the red X symbols and explanatory text. The way the information is now presented, it will grab your attention.
Figure 13 – IE7 Certificate Error 2 Notice the red URL and the “Certificate Error” message. Essentially, to go back to our story, Internet Explorer 7 is effectively saying “You may be at a fake ATM machine!” The big question is “How can digital certificates help me determine that I’m going to the right website?” Well, there are two main components around digital certificates – the digital certificate issuer (Issued by:) and the holder of the digital certificate (Issued to:).
Public Key Infrastructure and Public Key Certificate Basics Let’s go back to the certificate information dialog, shown in Figure 14: Figure 14 - Certificate Information Here is the message: “This CA Root certificate is not trusted.” To enable trust, install this certificate in the Trusted Root Certification Authorities store”. What the message is trying to say is that “HP Jetdirect 85C1F319”, who issued the certificate “HP Jetdirect 85C1F319”, is not trusted.
Unencrypted Message User Encryption Performed Message Delivery Decryption Performed User Unencrypted Message Figure 15 - Symmetric Cryptography In Figure 15, the confidentiality provided to the message is done via a single key. Because the same key is used for encryption and decryption, this process is known as symmetric cryptography.
Figure 16 - Asymmetric Cryptography Here we can see the difference between asymmetric and symmetric cryptography. One key can be used for encryption and then the corresponding key can be used for decryption. It appears that asymmetric cryptography has solved the key distribution issue; however there are two new attributes usually associated with asymmetric cryptography • • It is slow It has a trust problem.
• A hash – also known as a message digest. A hash is the output of a one way function that attempts to ensure the integrity of the message (i.e., that the message has not been altered). It is usually combined with authentication information to ensure that the message originator can be authenticated and that the integrity of the message has not been disrupted. You can think of a hash like an advanced checksum or an advanced cyclic redundancy check (CRC). Let’s cover hashes and digital signatures first.
Figure 18 - Digital Signature Verification Here we see how John uses Jack’s public key to verify the message. Jack’s public key is the only key that can decrypt the digital signature and obtain the hash value of the message that Jack calculated before sending the message. Because the hash was encrypted with Jack’s private key, which no one should know but Jack, John can be sure that Jack was the one that sent it.
Create Key Pair Jack’s Public Key Jack Jack’s Private Key CA’s Public Key Identity Info + Jack Jack’s Public Key CA’s Private Key Certificate Authority (Also performs Identity Verification on Jack) Certificate Request Jack’s Private Key (Stays Private) Identity Info + CA Info + Jack’s Public Key Preliminary Certificate One-Way Function/Hash Function Identity Info + CA Info + Jack’s Public Key Encryption CA’s Digital Signature Jack’s Public Key Certificate Figure 19 - Certificate Authority Jack
Figure 20 - Public Key Certificates Here we can see that everyone’s public key certificate is, well – um, public. The important thing to note is that the certificate authority also has a public key certificate that identifies itself. This certificate is signed with its own private key and is a “self-signed” certificate. As you may remember, Jetdirect also creates a self-signed certificate.
Create Key Pair Jack’s Public Key Jack Jack’s Private Key Jack’s Private Key (Stays Private) Identity Info + Jack Jack’s Public Key Identity Info + Jack’s Public Key Preliminary Certificate One-Way Function/Hash Function Identity Info + Jack’s Public Key Encryption Digital Signature Jack’s self-signed Certificate Figure 21 - Self-Signed Certificate Basically, Jack’s private key does the signing on his public key certificate.
authority’s self-signed certificate will have a purpose to create certificates for other entities, usually subordinate certificate authorities. It may be of help to go back to our driver’s license example to explain certificate purposes. A driver’s license purpose is to clearly identify the person it has been issued to and to show that that person has the right to drive in a given state.
Client Handshake TCP Connection Established SSL Record Server TCP Client Hello Supported Ciphers Random # Figure 23 -Client Hello Here we already have a TCP connection in place. The TCP connection was initiated by the client. Once we have this reliability, the client now sends the SSL Client Hello message to the server. This message has a random number and a list of cipher suites the client supports. Now it is the server’s turn in Figure 24 – Server Hello.
Figure 24 - Server Hello The server responds with a Server Hello message which includes another random number and the server selected cipher. It also sends back its public key certificate along with a message indicating that it is done with this part of the handshake. Now, the client has some work to do.
Figure 25 - Server Certificate Verification Here the client needs to verify the server is really who they say they are. There are a lot of checks against the certificate. If any of these checks fail, there is a good chance the client is not talking to the “real” server. Assuming that everything is fine, the client still has more work to do. It needs to come up with some keying material.
Client Client Random # Cryptographic Key Generation: PreMasterSecret Server Random # Server Public Key Encryption E(PreMasterSecret) Figure 26 - Keying Material The client generates what is called a “pre_master_secret” using the random numbers as well as a function called the key derivation function. This is encrypted with the server’s public key. Only a server with knowledge of the private key would be able to decrypt it.
Figure 27 – Client Finished The client goes ahead and sends over the encrypted pre_master_secret and let’s the server know that it is changing over to use the master_secret and proves that it knows the master secret by providing a cryptographic hash of all data sent over to the server.
Client TCP Connection Established TCP SSL Record Server Handshake Change Cipher Spec Finished Figure 28 - Server Finished The server decrypts the pre_master_secret and generates the master_secret. It goes ahead and let’s the client know that it is changing over to use the master_secret and proves that it knows the master secret by providing a cryptographic hash of all data sent over to the client.
Figure 29 - CA Heirarchy The network is really simple and is composed of these CAs, a DNS server, a client, and an HP LaserJet MFP. Refer to Figure 30 – Network Diagram.
Figure 30 - Network Diagram A pretty basic setup! The XP client is going to open a browser and talk to the 4345MFP. In short, the XP machine will be an SSL client and the 4345MFP will be an SSL server. In order to get SSL working properly, we are going to need to assign a certificate to the 4345MFP so that it can verify its identity correctly and pass all those checks that the client has to do. We’ll use regular HTTP and go to the Jetdirect page where we can perform our certificate operations.
Every Jetdirect will create a self-signed certificate the first time it is powered on. Each Jetdirect has a unique selfsigned certificate. For small environments, trusting the selfsigned certificate (by storing the certificate on the client) may be all that is needed for security. We can take a look at this certificate by pressing “View…” under the heading “Jetdirect Certificate” The subject and issuer names are the same – that is the first clue that it is a self-signed certificate.
We see the RSA public key is 1024 bits for the selfsigned certificate and that the certificate can be used for client and server authentication. We also see that the certificate has a signature – which means it has been signed (by itself in this case). Click OK and go back to the main screen.
Under the heading “Jetdirect Certificate”, press “Configure…” 31
Select the radio button “Create Certificate Request”. This will tell Jetdirect to create a public/private key pair and along with some more information that we be entered, generate a certificate request with the public that can be given to a CA. Jetdirect does not reveal the private key. Press “Next ->” Here we enter details to properly identify the Jetdirect device. Each customer will have different values here.
Here is the certificate request. We are going to want to store it. We can cut/paste it or click “Save”.
Store it in a directory on the client. Now we are going to bring up R2’s CA web server.
Enter the credentials that will allow a certificate to be issued. And here is the R2’s CA web server.
Click “advanced certificate request” Select the second link “Submit a certificate request….
We cut and paste the certificate request from Jetdirect into the box provided. We select a certificate template. This template is basically a “cookie cutter” for how to create a specific type of certificate. We have a template called “jetdirect” which has already been created. The only thing it really specifies is that the certificate can be used for Client and Server authentication. Click “Submit”. Click “Download certificate”. DER encoding is fine.
Save it.
Now we select “Install Certificate” and click “Next” Point it to the file obtained from the R2 CA.
Cool – it worked. Click “OK” Now – let’s view the contents of this certificate. We can see that the issuer is R2. We also see the Subject CN. This name will be important later on.
We see we have some CRL distribution points in the certificate as well – remember that. Also see that we can do Web Server and Web Client authentication. Let’s use HTTPS. Everything should be fine right? Wrong! The client has failed its server certificate checks. Why? It says that the Security Certificate was not issued by a trusted certificate authority. The browser’s certificate store must not know about our R2 and RootCA certificate authorities. Let’s correct that.
Click “Download a CA certificate, certificate chain, or CRL”. Select “Download CA Certificate Chain”. This file will have both R2 and RootCA’s public key certificate.
Save it. Go to “Tools” and click “Internet Options”.
Click “Certificates” 44
Click “Import…” Click “Next” 45
Select the file Click “Next” 46
Select “Automatically select the certificate store….
Press “Yes”. Note the Security Warning message. Installing a CA public key certificate as a trusted Root CA is a big deal. You need to be very sure this is what you want to do.
Select the tab “Intermediate Certification Authorities” and we can see that R2’s public key certificate has been installed. Yea! Click the tab “Trusted Root Certification Authorities” and we see RootCA has been installed.
Now we go back to the web page and still get an error!! No!! The problem is that we have a name mismatch. We are using the IP address in the URL and the IP address is no where to be found in the certificate. We need to use the name that the certificate has. Time to create a DNS entry for the printer. Here is our DNS entry which matches the Subject CN in the certificate.
We ping it just to be sure. Looks good. We go back to the web browser and enter the name instead of the IP address.
Everything worked! Now SSL/TLS is working for HP Jetdirect just like it would work for an Internet secure shopping experience. A Detailed Look at the SSL/TLS Connection Good stuff so far! Let’s bring up Wireshark and see what was actually happening on the wire during the successful https connection.
We see the TCP connection is established to “https” or TCP port 443. The client is 192.168.0.25 and the web server is 192.168.0.20. We see the SSL “Client Hello” message. Notice the detail. TLSv1 “Record Layer” and “Handshake Protocol”. Based upon our previous discussion, we know the client is going to send a random number and the cipher suites it supports.
Now let’s look at the server hello. Here we see a random number and the cipher suite selected to be used: TLS RSA WITH RC4 128 MD5 We see the server’s certificate. We can tell from the common name that it is the one we just assigned Jetdirect previously. This packet also contains the “Server Hello Done” message.
Here the client is sending over the pre_master_secret encrypted with the server’s public key. It is also letting the server know it is changing keys to the ones derived from the master_secret Same info coming from the server this time.
Now we have actual client data – this is probably the initial HTTP request encapsulated in SSL/TLS. There was one check that wasn’t done – the CRL. This check wasn’t done because it is disabled by default. Going into the “Internet Options” under the Tools menu for IE7, we then click the Advanced tab and look what we find.
Check for server certificate revocation is not selected.
Let’s select it and restart IE7. Here is another HTTPS connection to the same LJ4345MFP.
Here we go – looks like before any application data is sent, the CRL is check using http. This one is going to the RootCA Another CRL request to R2.
Here is the content of the CRL – encrypted of course. A performance hit would occur when CRLs are checked. That is probably why it isn’t checked by default. SSL/TLS Server Settings HP Jetdirect has a couple of useful settings to control how SSL/TLS clients connect to it. Let’s have a look. There are three main settings for the SSL/TLS server. One is the Certificate and we’ve covered that. The next one is the checkbox “Encrypt All Web Communication”.
The setting “Encryption Strength” controls the cipher suites that Jetdirect will select from a client request. The default setting is “Low” which is a bit misleading – it really means that all cipher suites that Jetdirect supports can be used including ciphers that aren’t considered as secure anymore. If the client can only support DES, Jetdirect will still accept it. However, if the client offers DES and other cipher suites, Jetdirect will prefer higher security ciphers when presented with the choice.
We are going to select Simple over SSL as the LDAP server bind method and use the IP address of 192.168.0.1, which is our LDAP server. We then scroll to the bottom and hit the “Test” button (not shown). We are asked for credentials and we provide them and hit OK.
Error message – it didn’t work. Let’s look at a trace. Here we see Jetdirect taking on the role of the client. It initiates the connection and sends the Client Hello.
The server responds. There is a new message here – one we haven’t talked about. The Certificate Request. The server is indicating to Jetdirect that it must send it certificate to the server to be validated. We are in good shape because Jetdirect already stored a certificate capable of doing Client and Server authentication. That is a good thing! Here we have a TLS Alert indicating Unknown CA. Jetdirect is sending this message to the server.
Because we have already stored the CA certificates in our browser’s certificate store, we’ll just export one and put it on Jetdirect. Let’s take a look at it.
Select R2 and hit “Export…” Click Next 66
Select DER. Click Next. Save it.
Save it.
Under the heading “CA Certificate”, click “Configure” Select Install and click “Next” 69
Select the file. Click Finish Click OK.
The status for the CA Certificate is now “Installed” We try again and it still fails! 71
Same message.
We need the ROOT CA. Jetdirect cannot use Intermediate CAs. Back to the certificate store and now let’s export RootCA’s public key certificate. Install it.
Try again. Another failure! Let’s check the trace. Here we get a “Certificate Unknown” message. Well, it could be we are using the IP address rather than the name. Let’s check that.
We use the DNS name and try again.
Now that we are successful, we see the server’s certificate has a SubjectAltName with a dnsName identifier. Remember that the server wanted Jetdirect’s certificate too. It sent us a “Certificate Request” and we sent back our Certificate just like we would do if we were a server. Now the server has to perform the appropriate certificate validity checks.
SSL/TLS Client: Understanding Certificate Chains In the previous section, we described a situation where the wrong CA certificate was configured on Jetdirect. Let’s explain this more thoroughly because it is a common issue reported on Jetdirect. Remember, Jetdirect is an embedded system and has limited flash space. Therefore, it cannot store a multitude of certificates on its flash file system. What Jetdirect needs to do is “Walk the Certificate Chain”. Let’s explain by reviewing our CA Hierarchy.
Figure 32 - Notice that R2’s certificate is issued by RootCA. What does RootCA’s certificate look like? Let’s look at Figure 33.
Figure 33 - RootCA Notice the RootCA is “self-signed”. All Root CAs will be self-signed – these CAs represent the single point of trust. A logical question would be: “Which CA do I configure on Jetdirect?” Let’s look at some diagrams. First, we have an incorrect configuration, as shown in Figure 34 – Incorrect HP Jetdirect CA Configuration.
RootCA’s Info + RootCA.example.internal RootCA’s Public Key Root Certificate Authority: RootCA RootCA’s Digital Signature RootCA’s Certificate R2.example.
RootCA’s Info + RootCA.example.internal RootCA’s Public Key Root Certificate Authority: RootCA RootCA’s Digital Signature RootCA’s Certificate R2.example.
Figure 36 - Walking the Chain 1 Jetdirect has one certificate stored on it – the RootCA public key certificate. During the SSL/TLS handshake with the LDAP server, two certificates are sent back to Jetdirect. One is the LDAP Server’s certificate and the other is the public key certificate for R2. Jetdirect stores them in its volatile memory and can begin to “walk the chain”.
Jetdirect verifies that R2 has signed the server’s certificate. It also verifies R2’s certificate (e.g., it has not expired and so on) and makes sure that R2’s certificate was signed by RootCA. This “walking the chain” functionality is very important for devices with limited storage space for certificates – like HP Jetdirect. SSL/TLS Client: Certificates and Name Verification You may remember that having “https://192.168.0.
Figure 38 - Subject We can se there are several things in the Subject – but the most critical is the Common Name. Here we can see why the browser URL of “https://192.168.0.20” would fail to pass the certificate check but “https://NPIC1F319.example.internal” would not fail. This interesting fact comes as a surprise to most people – the IP address is not usually part of the certificate (Note: IP addresses can be included in certificates). Another way of verifying the name is to use the SubjectAlternateName.
Figure 39 - SubjectAltName Notice how there isn’t even a Common Name in the LDAP server’s certificate. If you remember, we tried connecting to the LDAP server using the IP address of 192.168.0.1 and it failed. When we switched to w2003.example.internal, it passed. We can now see why. A name check was done between the FQDN specified for the LDAP server and the SubjectAlternativeName of a type of dNSName whose syntax is very well known.
Effectively, the algorithm is going to be something like this: If( dNSName is present) { Match dNS Name } Else { Match Common Name } For HTTPS, we saw that a mismatch caused a warning dialog box with Internet Explorer 6 and an explicit Certificate Error with Internet Explorer 7. Combining everything we have learned so far, we can form a very easy rule with SSL/TLS: One name to one IP Address to one port number identifies one certificate. For instance, looking at the previous trace: w2003.example.
Figure 40 - OU Here the Common Name is the FQDN of Jetdirect but there is additional information provided in the Organizational Units (OU). This same approach could be used for server farms where there would be several certificates with the same FQDN but differing in their OU values so that they will have separate public/private key pairs and provide better security over a single private key distributed to many servers.
(“https://msimpson.example.com” or “https://bsimpson.example.com”), they get a Certificate Error indicating a name mismatch. Why? If we refer back to our SSL/TLS protocol diagrams, we can see that the server must send back a certificate before it knows what website is being referenced. This is part of the SSL/TLS negotiation. It happens before HTTP can be used to indicate the website (via the ‘Host:’ header). There are a few ways to try and fix this problem.
IPP over SSL/TLS SSL/TLS can also be used to protect printing. HP Jetdirect supports IPP over TLS (henceforth, IPPS), but does not support any client authentication to control printing. Therefore, only server side authentication using the digital certificate can be done.
Click “Next” Select “A network printer…” 90
Specify a URL of HTTPS and be sure to end it with a “/ipp” so Jetdirect knows what it is for. Select the appropriate driver.
Click “Finish” Now we have a printer. Right Click and select properties.
Print a test page. Yep – we have our print data protected by SSL/TLS.
That wasn’t too bad to get security for your print data. However, there is a problem. Notice that we used the IP address in the URL. After the big section on name checking, we should know that there is not a way to verify our Jetdirect’s certificate with an IP address in the URL. IPPS should have flagged a certificate error but it did not. This behavior brings up an important point. Just because SSL/TLS is being used doesn’t mean the proper checks are being done.
physical user interface) and is probably stored right next to the digital certificate. In short, an analysis of the non-volatile storage of your embedded device may reveal more information than you want.
