Tag: ssl

Categories
Computers English Security

Get certificates for “internal” hosts from Let’s Encrypt

I have a pretty large internal IT “landscape” in my house, and as an IT pro I want everything to be clean and “safe.” So even internally I’m using official SSL (or I should say “TLS”, as SSL 2.0 or 3.0 is deprecated since many years…) certificates for my router, WiFi access points, NAS devices, intranet server, etc., using host names in my own domain. I host this domain DNS-wise myself on a root server I rent from Hetzner.

Before the StartSSL disaster I got my certs from them. Afterwards I switched to WOSign, but now that they had their scandal as well, what to do?!

Well, Let’s Encrypt, a free public CA, is something I’m using anyway for my root server since they started operating. But to verify ownership of a domain name you had to run a web server on that respective host — something I can’t easily do for my internal hosts, as they have private IP addresses only, and their host names are not even publicly visible (they don’t have  a public A record, only one visible in my internal LAN). Even for my router’s externally visible host name I can’t easily use an HTTP-based challenge, as for security reasons I don’t want to operate a web server there.

By chance I came across the dns challenge that is now available in Let’s Encrypt’s certbot. This challenge works by deploying a TXT record that certbot requests to be under this domain name. Once you did this, you tell Let’s Encrypt to check, and if they find the TXT record this proves that you have authority over the domain.

Using it is quite straight forward:

# certbot certonly --manual -d hostname.internal.bergs.biz --preferred-challenges "dns"
[...]
Please deploy a DNS TXT record under the name
_acme-challenge.hostname.internal.bergs.biz with the following value:

YrAE-fmu-Zjsdhsjhd328723hjdhjcjHJJHJhds

Once this is deployed,
-------------------------------------------------------------------------------
Press Enter to Continue

A few seconds later I had successfully received my certificate.

So now I will write a script that will run periodically on my intranet server, and that will retrieve the then-current certificates for my internal hosts from my root server, and deploy them internally.

Categories
Computers Security

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?! :-/

Categories
Computers Mac Security

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?

Categories
Computers Mac

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
ddc328ff
#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!