CAA record issues

In February 2018 I wrote about CAA records. CA’s must check and respect these records when a customer orders a certificate. This is a good thing and it can be a good security measure to use to minimize the risk of rogue WebPKI certificates.

But it is also coming with some downsides. Working at a WebPKI reseller I daily see problems with CAA records. Some of them are on the client site and some of them are on the side of the CA. I will address a few here.

Lack of communication at CA’s

When a customer orders a certificate, and it gets blocked because of a CAA issue, this is not visible to the customer or the reseller. And most of the CA’s we work with aren’t very active to send a message about this issue which results in a very large delay.

And when you are contacting the CA about the CAA issue the do not always know what the problem is. If it is more than a wrong CA in a CAA record. When it comes to DNS issues and with DNSSEC problems in particular, they can’t really tell you where it fails most of the time. If you ask the CA for some details about the CAA lookup errors they only tell you the global method, again. There are CA’s that are providing some more information, but it still isn’t transparent.

There are also some differences between CA’s with checking the CAA records and handling doubtful cases. We did a test with a request of a certificate which was rejected at one CA, but accepted by an other CA.

At the end, it comes to clear communication en transparency.

Technical problems

Most of the time, the technical problems are on the client side. CAA check’s are less strict when you do not have DNSSEC enabled on your domains. But when you DO have DNSSEC enabled, you have to ensure that there are totally no errors in your DNS configuration.

Living and working in The Netherlands, where DNSSEC is pushed by SIDN (that is a really good thing by the way) there are many hosting providers that have enabled DNSSEC on their nameservers in a rush because of the financial benefits. SIDN gives registrars a discount on every DNSSEC signed domain. The “rush” to implement DNSSEC was not very good for the quality of the implementation in my opinion.

More then 50% of the .nl domains are signed. https://stats.sidnlabs.nl/en/dnssec.html

With anomalies on the DNSSEC side and DNS administrators who are using exotic configurations the risk of an error is very high. Beside that, my experience with many system and network administrator is that they one have some basic knowledge of DNS. DNS is a bit the “forgotten” protocol that just is there to use.

In case of an error on a DNSSEC enabled domain, a CA may not issue a certificate for your domain. So you need to solve your DNS problems.

Regional problems?

This maybe is a bit of a hunch, but the CA’s are telling us that there are timeouts while doing the CAA lookup. When a CA has his systems in the US and it needs to resolve many CAA records fast, they need to work with a small timeout periods. When a Dutch hosting provider only have nameservers located in the Netherlands, an initial lookup can be just a bit to long. CA’s are giving the timeout message almost only on domains that are hosted at cheap hosting providers that do not always have a very good performance.

Usage

Seeing CAA records multiple times a week I’m wondering if there are usage statistic. But at the moment I only can find the stats on SSL Pulse. https://www.ssllabs.com/ssl-pulse/

CAA-SSL-Pulse2

Starting a project

With the CAA “problem” in mind I started a project on Github with a Go library where I test for CAA records and problems. My coding skills are not that good, but I try to make the best of it. And it also is in a concept stage at the moment. The library search for CAA records following the procedure that I explained in another blog post about CAA records.

I’ve also created a test website to test for CAA records. Check https://test.binaryfigments.com/ for this. It may be a bit buggy at the moment, but I will maintain this site.

Or you can take a look  at some results: https://test.binaryfigments.com/run/bcg2v1rk2bfp2a8lus00

Update

Searching the code of Let’s Encrypt, I came across some good reference about handling CAA records at Let’s Encrypt.

https://github.com/letsencrypt/boulder/blob/9c2859c87b70059a2082fc1f28e3f8a033c66d43/va/caa.go

They also have some nice documentation.

https://letsencrypt.org/docs/caa/

 

Create a PKCS#12 / PFX file with OpenSSL

For some reason I get this question a lot:

For my Linux webserver I have a SSL/TLS certificate from a CA and my private key. Buy I also want to use it on a Windows Server. How do I create a PFX file so I can easily import the certificate?

The easiest way to do this, is using OpenSSL on your webserver. But there are also OpenSSL binaries available for Windows.

What do you need to generate a PKCS#12 / PFX file?

  • The certificate for your domain
  • The private key that is corresponding with this certificate
  • The intermediate certificates of the CA

In my example I have 3 files.

sebastian@research:~/Certificates/pfx$ ls
service-ca.pem service-cer.pem service-key.pem
  • service-ca.pem = the intermediate from the CA
  • service-cer.pem = the certificate for my domain
  • service-key.pem = the privcate key

With the following command you can create the PFX file:

openssl pkcs12 -export -out service.pfx -inkey service-key.pem -in service-cer.pem -certfile service-ca.pem

OpenSSL will ask you to set a password for security reasons. Remember this password. After entering this, you are finished.

sebastian@research:~/Certificates/pfx$ openssl pkcs12 -export -out service.pfx -inkey service-key.pem -in service-cer.pem -certfile service-ca.pem
Enter Export Password:
Verifying – Enter Export Password:

To check a PKCS12 or PFX file, you can run this command:

openssl pkcs12 -info -in service.pfx

It ask you several times for the password that you used to get all information.

sebastian@research:~/Certificates/pfx$ openssl pkcs12 -info -in service.pfx
Enter Import Password:
MAC:sha1 Iteration 2048
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Bag Attributes
localKeyID: 8F 00 8A 50 4B 27 4B 1A 21 A1 13 7E 4E FA 56 87 78 E4 00 91
subject=/CN=service.xxxx.nl
issuer=/C=NL/O=Trust Provider B.V./OU=Domain Validated SSL/CN=Trust Provider B.V. TLS RSA CA G1
-----BEGIN CERTIFICATE-----
MIIGFTCCBP2gAwIBAgIQB25+xctodWXWr4G8Z2kJMTANBgkqhkiG9w0BAQsFADB2
9zBYYlxcH6tAaG0P8Swbs/UQd1uiEjofZWJaS5TL0QhabNn4LUfJOABHkwqv6dJc
LWXfeo5a6LslgkjsX/wDCBteAbFFneyOaA==
-----END CERTIFICATE-----
Certificate bag
Bag Attributes: <No Attributes>
subject=/C=NL/O=Trust Provider B.V./OU=Domain Validated SSL/CN=Trust Provider B.V. TLS RSA CA G1
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2
-----BEGIN CERTIFICATE-----
MIIEsjCCA5qgAwIBAgIQDsQR7fAC9zA2xOXULz408jANBgkqhkiG9w0BAQsFADBh
8iyF7aYLP9rUBg+UEJ0s55VrTPKUDYyuAKXyODwgmtuYiZMDrQPcwGfRO1GDghIT
3dI21ici
-----END CERTIFICATE-----
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
Bag Attributes
localKeyID: 8F 00 8A 50 FB 27 F8 1A 21 A1 13 7E 5E FA 56 87 78 E4 00 91
Key Attributes: <No Attributes>
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFHDBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQIk+eDqk520VICAggA
X1YZEYnnhTp0abOi6/ART1dh4x1KRPT5DjbUVyLdH4vwnFl1gTiWMwROzOrkERXU
icsavzmZ3xRDX02OvYG/EQ==
-----END ENCRYPTED PRIVATE KEY-----

Some information is changed in this example. But you can see on your machine that is works.

 

Are you using CAA records?

With the approval of ballot 187 the Certificate Authorities must check and respect the CAA records that are found in the DNS of a domain. This additional check is active since September 17, 2017. CAA stands for Certification Authority Authorization and  is a standard designed to help the owners of a domain by preventing the issuance of rogue or unauthorized SSL/TLS certificates for that domain.

Read more

PostgreSQL and SSL/TLS

Encryption of data in transfer is not only important for web servers and mail servers. You can also use SSL/TLS on database servers like PostgreSQL. This will make the usage of an SQL server on the internet a little bit more safe.

As a regular PostgreSQL user I sometimes have to lookup some settings to make PostgreSQL available over an SSL/TLS connection. Now it’s time to share some notes about this.

To allow the usage of TLS/SSL on the PostgreSQL database server, we have to edit some configuration files.

First: /etc/postgresql/9.6/main/postgresql.conf

# vim /etc/postgresql/9.6/main/postgresql.conf

Here we add the following configuration:

# - Security and Authentication -
ssl = on
ssl_ciphers = 'AES128+EECDH:AES128+EDH'
ssl_prefer_server_ciphers = on
ssl_cert_file = '/etc/postgresql/cert/cert.crt'
ssl_key_file = '/etc/postgresql/cert/private.key'
ssl_ca_file = '/etc/postgresql/cert/cacert.crt'
password_encryption = on

If you want to access the PostgreSQL server from a remote server, you also have to allow PostgreSQL to listen on the IP addresses on the network interface.

listen_addresses = '*'

Be sure that you set the right file system permissions on the certificate files.

chown postgres:postgres -R /etc/postgresql/cert
chmod -R 700 /etc/postgresql/cert
chmod -R 600 /etc/postgresql/cert/*

When you are connecting from a remote system, you also want to add an extra line in the pg_hba.conf configuration file like this:

# My custom hosts (change your IP address here)
# TYPE    DATABASE   USER   ADDRESS        METHOD
hostssl   all        all    12.34.56.78/32 md5

Now you can login from a remote host using SSL/TLS. Let me explain quickly how to create a user, database and a password to test the connection:

Create a PostgreSQL user:

sudo -u postgres createuser testuser

Create a PostgreSQL database:

sudo -u postgres createdb testdb

Connect to PostgreSQL, create a password and give the test user the right privileges to the database.

sudo -u postgres psql
psql=#

SQL commands:

psql=# ALTER USER testuser WITH ENCRYPTED PASSWORD '';
psql=# GRANT ALL PRIVILEGES ON DATABASE testdb TO testuser ;

Now, test the connection:

sebastian@desktop:~$ psql -h postgresql.server.net --u testuser -d testdb -W
Password for usertestuser: 
psql (9.6.6)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES128-GCM-SHA256, bits: 128, compression: off)
Type "help" for help.

testdb=>

Here you can see that you can connect with SSL (Protocol TLSv1.2).

That’s it! Feedback is welcome!

Wat is SSL / TLS inspection

SSL / TLS inspection is een techniek welke al lang bestaat maar die men steeds vaker toe gaat passen. Normaal gesproken gaat het internetverkeer vanuit de werkplekken binnen een bedrijf via een firewall en/of naar een website of internetapplicatie. Nog niet heel lang geleden ging het meeste verkeer over een on-versleutelde HTTP verbinding. Dit verkeer was makkelijk te controleren en bijvoorbeeld tegen te houden als er iets schadelijks tussen zit. Tegenwoordig is een versleutelde HTTPS verbinding de norm. Doordat HTTPS verkeer versleuteld is, is het moeilijk om bijvoorbeeld virussen of malware in dit verkeer te detecteren of is er geen controle op de informatie welke verzonden word naar een derde partij. Steeds meer bedrijven zien dit als een probleem.

normal-https
Normaal SSL/TLS verkeer door een firewall naar een website

Versleutelen, ontsleutelen en weer versleutelen

Om SSL / TLS inspection te kunnen toepassen is er een “Man in the Middle” nodig (MitM). Deze MitM is vaak op basis van een proxy server en vangt het versleutelde verkeer op en ontsleutelt het zodat er gekeken kan worden wat er in zit. Vervolgens gaat het weer verder naar het doel. Om dit zonder SSL/TLS foutmeldingen op de werkstations te doen binnen een netwerk, is er een interne certificate authority nodig met een eigen root certificaat. Over het algemeen zit deze functionaliteit in de firewall zelf. Het root certificaat zal op de werkstations geïnstalleerd moeten worden in de certificate stores waar nodig.

https-with-inspection
TLS / SSL verkeer via een firewall en proxy voor SSL/TLS inspection naar een website.

Welke stappen worden doorlopen?

Een gebruiker gaat vanaf een werkstation (met het interne root certificaat) naar bijvoorbeeld https://www.dodgydonuts.com/ om een bestelling te plaatsen.

  • De gebruiker gaat in de browser naar https://www.dodgydonuts.com/
  • De gateway binnen het netwerk vangt dit verkeer af en stuurt dit naar een proxyserver.
  • De proxyserver vraagt onderwater bij de interne CA een certificaat aan voor www.dodgydonuts.com welke op het interne root certificaat zal worden uitgegeven.
  • De proxyserver stuurt het verzoek op zijn beurt weer door naar de website.
  • De website geeft antwoord aan de proxy server.
  • De data in dit antwoord gaat weer door de inspectie en zal hierna doorgegeven worden aan de browser van de gebruiker.
  • Doordat het werkstation dit root certificaat vertrouwd zal de browser geen foutmelding geven en gewoon een slotje aangeven in de browser.

Welke componenten zijn nodig hiervoor?

Om SSL / TLS inspectie technisch toe te kunnen passen zijn de volgende componenten nodig in het netwerk.

  • Een proxyserver. Deze proxyserver is nodig om het verkeer te kunnen scannen op malware, virussen en documenten welke het bedrijf niet via het internet mogen verlaten.
  • Een interne certificate authority met een geldig zelf gegenereerd (self signed) root certificaat welke geïnstalleerd zal moeten worden op de computers en andere apparaten.
  • Een firewall welke bijvoorbeeld het https verkeer transparant doorstuurt naar de proxyserver, of instellingen in de browsers binnen het netwerk waarin staat dat de proxyserver gebruikt moet worden.

Wat zijn de voor en nadelen?

Natuurlijk zitten er aan voor en nadelen aan deze oplossing vast welke niet alleen van technische aard zijn maar ook organisatorisch. Hoe zal er worden omgegaan met de privacy van de gebruikers?

Waarom doen?

  1. Application Control. Toegang tot bijvoorbeeld cloud applicaties als Dropbox of OneDrive kan beperkt worden.
  2. Intrusion Detection / Protection. Doordat het verkeer te analyseren is kunnen intruders makkelijker gevonden worden.
  3. Antivirus en antimalware. Verkeer is door deze techniek te scannen op virussen en malware waardoor deze bij de ingang van het bedrijf al te stoppen zijn.
  4. Filteren. Het internetverkeer is te filteren op websites en diensten welke niet zijn toegestaan te bezoeken of te gebruiken binnen het bedrijf.
  5. Data Loss Prevention. Omdat de bestanden die verstuurd worden via het internet nu te lezen zijn, is het mogelijk om bepaalde bestanden tegen te houden, of bij te houden welke medewerker wat naar wie verstuurt. Dit onderwerp is de laatste tijd een hot-issue! Niemand wil natuurlijk dat er data vanuit het bedrijf uitlekt naar buiten toe aan partijen die hier schade mee kunnen aanrichten of waarbij bijvoorbeeld persoonsgegevens gelekt worden.

Waarom niet doen?

  1. Privacy problemen. Ja, ook werknemers hebben recht op hun privacy. Maar hierdoor dus goede afspraken en leg deze vast in het internet protocol van uw bedrijf.
  2. Technieken die de MitM tegenhouden kunnen voor problemen zorgen. Zorg ervoor dat de websites en applicaties die deze technieken gebruiken wel bezocht kunnen worden door uitzonderingsregels te te passen.
  3. Public Key Pinning, een techniek die nog niet heel erg ver doorgevoerd is, en eigenlijk ook weer op zijn retour is door de risico’s die eraan vastzitten. De browsers met HPKP ondersteuning zullen een foutmelding geven bij het bezoeken van deze websites. Deze kunnen dus ook op de lijst van uitzonderingen toegevoegd worden.
  4. Het afzwakken van de SSL / TLS implementaties. Oudere firewalls met de mogelijkheid voor SSL/TLS inspection dwingen soms een lagere TLS standaard af dan dat de website aanbied. Als een website TLS 1.0 tot en met 1.2 aanbiedt, maar de firewall eigenlijk alleen maar TLS 1.0 ondersteunt, is de beveiliging van deze website dus eigenlijk afgezwakt. Het is daarom belangrijk om dit goed in te stellen en te voorkomen. Ook is er geen verschil te zien tussen een domain validated en een extended validated certificaat.
  5. Omgaan met verlopen of ingetrokken certificaten van de website. Hoe gaat SSL/TLS inspection daarmee om? Omdat de certificaten door de interne CA worden gegenereerd en uitgegeven zullen deze gewoon geldig zijn volgens de browser. Wat nou als een bezoeker een website bezoekt waarvan het certificaat verlopen of ingetrokken is? Stel dit goed in zodat hier geen problemen door kunnen komen.

Zo zijn er nog veel meer redenen om wel of geen SSL/TLS inspection toe te passen is. Indien deze techniek wel toegepast zullen gaan worden binnen het bedrijf, zorg er voor dat niet al het verkeer door de SSL/TLS inspection heen hoeft te gaan door uitzonderingen op de regel toe te staan. Denk aan websites en applicaties van overheden, financiële of medische instellingen. Data van en naar onder andere deze instellingen moeten altijd zo veilig mogelijk verstuurd worden.

Andersom!

Natuurlijk is SSL / TLS inspection ook andersom in te zetten. Denk aan een reverce proxy of een web application firewall. Deze vangen ook het SSL/TLS verkeer af bij binnenkomst waarna deze onversleuteld geïnspecteerd kan worden om zo zaken als SQL-injections of Cross-Site scripting te detecteren en te blokkeren.

Waar zijn deze technieken te vinden?

Tegenwoordig zijn deze technieken terug te vinden in de modernere firewall’s. Vaak maken ze je het ook gemakkelijk door veel instellingen vooraf al goed te zetten. Denk aan firewall’s van bijvoorbeeld Fortinet, CheckPoint en SonicWall, ze kunnen het over het algemeen allemaal. Vaak hebben ze ook de optie om als web application firewall te dienen. Leveranciers als Barracuda, Qualys, Symantec (met Blue Coat) en CloudFlare hebben specifieke web application firewall oplossingen.

Hou er rekening mee dat het helaas ook wel eens mis kan gaan:

Maar kijk naar alle SSL vulnerabilities van de afgelopen tijd, die zijn ook niet mis.