netsekure rng

I want to share a story that had me completely puzzled and frustrated. I had to install PGP Desktop for something I’m playing with. I was amazed by PGP (the company) because I thought those guys understand security, the concept of digital signatures, and the crypto area in general. Well, believe it or not I had changed my opinion. After receiving the PGP Desktop zip file, I cracked it open to install the software. What do I find? Another zip file inside it along with a PGP signature file.

This is all good and the idea is that you should verify the signature of the installer to ensure it comes from the actual author. But this is a chicken/egg problem. I need to PGP to verify the installer, but I cannot since I’m trying to *install* PGP. I moved on, since there was no way (without using some other PGP package) to verify the installer zip file. So I fire up the installer on a test machine to see how it will go. To my surprise the installer comes from “Unknown Publisher”.

Hmm, I would think PGP being a security company selling encryption/signing software would definitely sign their code, but I guess I assumed too much. Since this was on a test machine, I decided to go through the entire process and see what happens. Maybe they launch another installer from inside it that is signed. They do have a MSI package inside it that gets installed, but it is still not signed :(

Total failure in my book for PGP. After I installed the software, I decided to verify the signature on the zip, since I now had PGP Desktop installed : ). Here comes the next surprise. PGP automatically looks up the key that has signed the package (cool), downloads it (cool), and verifies the package (cool). But what do I see in the log?

The key is invalid?!? Turns out that I have to explicitly download the PGP Release Key into my keyring for it to verify properly and say the key is valid. I wouldn’t mind doing this step (even though some of the PGP keys should be really shipping with the product), but if you are going to do the download for me, please do it properly. It only worked after I had manually copied the key ID from the invalid key, downloaded it to my keyring, and tried verifying the file again. (Nevermind that the log doesn’t have timestamp associated with it).

My usual approach is to always double check things that seem as weird as this. I thought I might have missed some support article or some other resource outlining the proper way to verify and install PGP. So I hop on support chat with PGP. I would leave it up to you to interpret the chat log yourself:

SupportTech: Hi, my name is SupportTech. How may I help you?
Nasko: Hello
Nasko: I wanted to ask a question about the installation of PGP Desktop
Nasko: I got the zip file that contains another zip file and a .sig file (the signature)
Nasko: How do I verify the signature ?
Nasko: It seems it is PGP signature, but me trying to install PGP, it seems like the chicken/egg problem
SupportTech: Unfortunately the only way to verify the signature is by having a previous version of PGP Desktop installed or after installing the software.
Nasko: Well, if I’m first time customer, there is no way for me to verify the zip file
Nasko: And what bothers me even more
Nasko: your installer is not signed, so it comes from “Untrusted” source
Nasko: How do I know what I am installing is indeed PGP Desktop from PGP?
SupportTech: For one, you need to login to LEMS in order to receive the download link. Since this is a secure site you can verify from the certificates that you are indeed downloading from PGP Corporation.
Nasko: is the actual download performed over https?
Nasko: Even if it is, I would feel a lot more comfortable if the installer is a signed binary
Nasko: such that Windows actually recognizes the author
Nasko: PGP is a security company after all
Nasko: and, no, the download link is not HTTPS
Nasko:  http://download.pgp.com/{random_url_part}/PGPDesktop9.12.0_Windows.zip
Nasko: what prevents a man-in-the-middle to replace the file on the wire ?
SupportTech: I understand that concern but it is currently not available in the installer. I do not have any information on if our development team plan to incorporate it.
SupportTech: Correct, it is not an HTTPS download.
Nasko: Is there any way customers can file issues or requests for the product?
SupportTech: Yes, there is this form:  http://www.pgp.com/products/feature_request_form.html Which goes directly to our developers.
Nasko: Thanks

I would give them props for at least having a way to relay feedback to the developers. This was the only ray of light in this whole mess.

In conclusion, I wouldn’t be bothered as much by all of this if the product was free. But for the steep price I expect polished product, not something I have to wrestle with for a day just to get up and going. So if you are security conscious and don’t have existing PGP software, you just don’t have any way to trust the product!

P.S. I am skipping the whole problem of PGP Desktop messing up my networking stack. You can get the idea from this  KB article, though the installer failed to create the rollback file, so I had to do all this by hand : (.

I recently spent some time looking at a very interesting issue, so I wanted to share it and save people some time troubleshooting similar issues. The problem was that a site requiring TLS client authentication was loading very slowly – about 30 seconds page loading time for the index page, which to say the least on today’s fast networks is incredibly slow. The setup was as follows:

Client Browser <—> ISA <—> Web Server

Naturally the first step was to look at what was happening on the wire. Firing off a sniffer and capturing the traffic, the strange thing was that there were multiple Change Cipher Spec (CCS) TLS messages. In general, when you negotiate a SSL/TLS session, you do Change Cipher Spec once and from there on the traffic is encrypted and flows between the client and the server. After spending some time looking at different traces one thing came out as a pattern – the number of encrypted CCS messages was roughly equal to the number of HTTP requests made from the client minus the number of TCP/IP connections used by the browser. So I fired up the debugger to help us confirm that this was indeed the case. Debugging the Microsoft SSL/TLS implementation is a bit tricky, since the handshake processing happens in the lsass.exe process (which hosts all security protocol providers) and the actual encryption/decryption of data happens in the process using TLS (the browser in this case). Some debugger tricks and a few sweat spots later, it was confirmed that for each HTTP request the server will send a HelloRequest message back to the client, which is the protocol message used by servers to force clients to reauthenticate. It was very strange that for each resource the brower fetches from the server a new renegotiation is required, since this is not the normal mode of operation.

What’s next in the network path after the browser – the ISA server. After digging around all the settings, what picked the attention was the setting below:

In the case of the slow config, the checkbox was unchecked and the timeout value was greyed out, though still showing 300. What the admin assumed is that 300 is the default value, so the unchecked box didn’t matter much. Well, what it really means is that the ISA server will *not* cache the client certificate at all, which in turn causes the client to authenticate for each request it sends to the ISA server. Needless to say, once the checkbox was checked, there were no extreneous CCS messages exchanged and the page was loading much much faster.

I never suspected that such an innocent looking checkbox can cause so much trouble : ).