search

drwetter / testssl.sh

Testing TLS/SSL encryption anywhere on any port
https://testssl.sh
GNU General Public License v2.0
7.92k stars 1.02k forks source link

DNS CAA record leftovers: CNAME + check #588

Open EmPeWe opened 7 years ago

EmPeWe commented 7 years ago

see: https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization rfc: https://tools.ietf.org/html/rfc6844

drwetter commented 7 years ago

see a3a30c7fa5e7dbae46e7804d1b21feb643b1cdb2 .

prompt %  EXPERIMENTAL=true ./testssl.sh --json -S google.com                           
[...]

 Certificate Revocation List  http://pki.google.com/GIAG2.crl
 OCSP URI                     http://clients1.google.com/ocsp
 OCSP stapling                --
 DNS CAA RR record            OK ("symantec.com")

 Done 2017-01-17 11:18:25    -->> 172.217.20.14:443 (google.com) <<--

prompt % tail -8 google.com_443-20170117-1118.json  
,        {
              "id"           : "CAA_record",
              "ip"           : "google.com/172.217.20.14",
              "port"         : "443",
              "severity"     : "OK",
              "finding"      : "DNS Certification Authority Authorization (CAA) Resource Record / RFC6844 : offered"
         }
]

prompt %

Still to do

  1. check old binaries whether they support this record at all
  2. check whether hexstring is returned and deal with it (e.g. Debian 8)
  3. check more than domainname, see https://tools.ietf.org/html/rfc6844#section-3
  4. check whether $1 is a CNAME and take this instead
  5. query with drill
drwetter commented 7 years ago

2.: done

  1. check returned CAA RR against CA
drwetter commented 7 years ago

see 8dabc28. commit message was screwed up. Missing first line: 3 is not also resolved as per RFC testssl retrieves the issuer critical flag and ONE property name/value pair and displays the pair (not the issuer critical flag yet)

open:

  1. check whether $1 is a CNAME and take this instead
  2. query with drill
  3. check returned CAA RR against CA
  4. deal with more than one property name/value tag (need example here)
EmPeWe commented 7 years ago

Big thx for your great effort and your transparency. Let me know if you need any further assistance.

drwetter commented 7 years ago

thanks!

I didn't spend much effort in testing and my only guineapig was google.com. Specifically I am looking for more candidates.

(7) still is an issue which needs to be addressed:

prompt% host -t type257 posteo.de  
posteo.de has CAA record 0 iodef "mailto:hostmaster@posteo.de"
posteo.de has CAA record 0 issue "d-trust.net"
posteo.de has CAA record 0 issuewild "startssl.com"
posteo.de has CAA record 0 issuewild "d-trust.net"
posteo.de has CAA record 0 issue "geotrust.com"
posteo.de has CAA record 0 issuewild "geotrust.com"
posteo.de has CAA record 0 issue "startssl.com"

testssl.sh shows only one line.

@k0ste: care to help with (5)?

EmPeWe commented 7 years ago

some more CAA candidates:

maybe I'll generate some entries for my own domain with https://sslmate.com/labs/caa/

k0ste commented 7 years ago

@drwetter, #633.

drwetter commented 7 years ago

Still work needs to be done:

Btw: weird entry from google.com:

# host -t type257 google.com 
google.com has CAA record 0 issue "pki.goog"
# host pki.goog   
pki.goog has address 216.239.32.29
pki.goog mail is handled by 30 alt3.gmr-smtp-in.l.google.com.
pki.goog mail is handled by 20 alt2.gmr-smtp-in.l.google.com.
pki.goog mail is handled by 5 gmr-smtp-in.l.google.com.
pki.goog mail is handled by 10 alt1.gmr-smtp-in.l.google.com.
pki.goog mail is handled by 40 alt4.gmr-smtp-in.l.google.com.
#
EmPeWe commented 7 years ago

Great to see the progress evolving :+1:

drwetter commented 7 years ago

Thx!

What was not clear to me while looking at it: How to match the DNS record against the certificate. There's no domain in the certificate. All information people were referring to was a somewhat shady sheet (https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00023) which didn't help much, to phrase it politely.

So how are the type257 records matched with the certificate issuer?

Cheers, Dirk

EmPeWe commented 7 years ago

You mean, where is the missing link between the CAA record (e.g. digicert.com) and the certificate issuer (e.g. DigiCert SHA2 High Assurance Server CA (DigiCert Inc from US))?

I'm not sure, but maybe this will help? https://community.letsencrypt.org/t/2017-09-08-caa-checking-algorithm-incident/42516

drwetter commented 7 years ago

Long week, but I do not see how it will help. E.g. posteo : one of the records in DNS is issue "geotrust.com". Issuer from the host certificate is GeoTrust EV SSL CA - G4, intermediate GeoTrust Primary Certification Authority

PS: Funny that Google's G2 is signed by Geotrust. One would assume that the announcement for not supporting some Symantec certificates anymore would come after changing the issuer. That GeoTrust Global CA is also SHA1 signed by Equifax...

drwetter commented 6 years ago
MrSeccubus commented 6 years ago

Re issuer check. What is it you mean to check?

drwetter commented 6 years ago

?

MrSeccubus commented 6 years ago

Sorry for that. Some incompatibility between my fingers and the tiny keyboard of an iPhone ;).

I noticed that on your roadmap, you want to match the certificate with the CAA records, but that would actually be quite some work for very little gain.

CAA records are only meant to restrict which CA can issue certificates for a certain domain, they do not impact any existing certificates. In that sense they are a lot easier to implement and change then HPKP header, as they do not get cached either.

drwetter commented 6 years ago

well, at a a certain point it would be great to detect whether a CA issued a certificate for a domain for which it was not supposed to. This check is since a month mandatory for issuers.

Realistically due to the missing automated checks it'll be way down the road....

MrSeccubus commented 6 years ago

Dirk, the CAA record is not intended to give a value judgement on certificates that are on a site. If you implement this feature like that you start to give people the impression that it is. It might even force people to keep CAs in their CAA record which they are no longer using and thus hurt security.

E.g. say I am currently using Comodo as my CA and I have a couple of hundred certificates with them and tomorrow I decide that I'm going to move to letsencrypt, then is should change my CAA record from "comodoca.com" to "letsencrypt.org", but it is NOT going to invalidate any of my current certificates from Comodo which I'm going to phase out slowly.

If you are harsh in the matching, people might actually decide to keep both comodoca.com and letsencrypt.org in their CAA records.

The only value is see is a warning like: Your current CA certificate doesn't appear to match your CAA records. If your current certificate expires, you cannot renew it with this CA, instead you will need to get a new certificate from one of the providers in your CAA records.

WRT to matching logic. I looked at a few and the string in the CAA records always seems to be a substring of the AIA issuer attribute of the certificate (1.3.6.1.5.5.7.48.2).

drwetter commented 6 years ago

You can be assured that I understand all that. It's a matter of phrasing the non-match (similar to your suggestion) and probably one can also have a look at the issuing date. You probably realized that I moved away from the "OK" in CAA section yesterday. The green color needs to be replaced, too.

There are lot of practical pitfalls one can detect and it would be worth raising the hand. Not marking a mismatch (if machine detectable) in a specific way would be not in a sense of this tool.

Thanks for the hint with the OID.