Tag Archives: ssl

Insecure self-updates via plain HTTP

Yesterday I discovered by chance (since I was running the program whose name I will not disclose yet on my Mac where I’m using Little Snitch to control outgoing connections) that a program created by one of the few software giants does not use SSL to ensure the integrity of self-updates, but just uses plain HTTP so that attackers can modify downloads and thereby introduce malicious code.

Immediately I got in touch with the manufacturer of the application, and only 9 hours later they came back to me with the below response:

Right now <unnamed product> download server supports only HTTP and not HTTPS, so we don't have any immediate solution to offer. However we are keeping notes of this concern and we will address it.

Is this not simply unbelievable?!

Remember we’re not talking about someone who does this for a hobby, who may not have the money or time or even knowledge to implement SSL on their server. But we’re talking about one of the largest IT companies in the world… :-(

I will now wait for a while, and if they haven’t fixed the issue by then I will disclose it on my blog anyway to put pressure on them… But maybe they do it intentionally in order to aid the NSA?! :-/

iTunes app downloads are unsafe…

I recently bought Little Snitch because it was on sale, and just found something strange…

I launched iTunes to download an app that’s currently available for free (ok, so I am a cheapskate… ;-)), and when the actual download was about to start Little Snitch asked for confirmation to allow iTunes to connect to phobos.apple.com on port 80, meaning that the download is not protected by SSL…

IMHO this is a big security risk since it allows attackers to manipulate your download and replace the original app by another one (e. g. one that contains malicious code).

I can’t see any reason why Apple would intentionally not protect downloads by SSL — it just seems to be very bad, careless design… :-(

What do you think?

Mac OS X “svn” client doesn’t know about common CA certs

I recently stumbled across a problem with Mac OS X Leopard’s “svn” (Subversion) client which doesn’t know about common root CAs (such as Thawte in my case,) even tho they are in the system keychain (which you can view using “Keychain Access.”)

It turned out that it only uses the certificates it find in /System/Library/OpenSSL/certs.

The strange thing is that the Thawte certificate in fact is already present on Mac OS, but it’s inside /usr/share/curl/curl-ca-bundle.crt, which svn doesn’t know about. So what I did to make it work is the following:

I extracted the certificate from /usr/share/curl/curl-ca-bundle.crt and copied it to /tmp/thawte.pem. I then determined the hash of the certificate as follows and created a link to the original certificate bundle (as superuser!):

#openssl x509 -in /tmp/thawte.pem -noout -hash
#ln -s /usr/share/curl/curl-ca-bundle.crt /System/Library/OpenSSL/certs/ddc328ff.0

Voilà! Now I could connect to our Subversion repository without receiving a warning like the following:

Error validating server certificate for 'https://our.repos.de:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!