6 ms·

How I got a valid SSL certificate for my ISP's main domain

68 points by mdewinter 12y ago

smt88 12y ago
I've never seen a provider of SSL certificates (or any other service) allow you to "prove ownership" of a domain by receiving an email. Even from the early days of email, it has never been the case that a majority of a domain's email addresses were assigned to owners of the entity. That is just absolutely insane.
- justinsb 12y ago
  Proving ownership by sending email to the contacts in the WHOIS record is the _only_ way I've seen for the cheapest certificates. What other ways are you thinking of, and can you point to any CAs that do them (for their cheapest certificates)?
  - smt88 12y ago
    I have no problem with that, but that's not what happened in the article.
    - stephenr 12y ago
      Where does it say that isnt what happened? It's entirely possible the WHOIS data for the domain in question had several email addresses listed, at least one of which was not blacklisted for use by clients.
  - ams6110 12y ago
    Years ago you had to do things like fax an approval letter printed on company letterhead.
    - toast0 12y ago
      Whenever we need something on leterheas, our GC makes up letterhead on the spot using images on our media resources page.
- patio11 12y ago
  I think it's Old Webmaster Lore that there exist roughly ten email addresses which are Widely Considered To Be Special. abuse@, postmaster@, and administrator@ are three of them. There exist a lot of systems in the world which rely on this being true, irrespective of whether it is in fact true.
  - tomjen3 12y ago
    I seem to recall DNS being one of them, that is that you have to have somebody monitor abuse@. But either way, this is yet another reason to ditch certificates: it is way too fragile a system (not the least because it gives users the "it has a lock, it means it is safe").
  - helper 12y ago
    Is the rest of the list you are thinking of RFC2142?[1] [1]: https://www.ietf.org/rfc/rfc2142.txt https://www.ietf.org/rfc/rfc2142.txt
- mukyu 12y ago
  Email is an incredibly common method for domain validated certificates. The other common options are a TXT/CNAME record or uploading a specific file to a certain URL. The requirements for domain validation are: 11.1.1 Authorization by Domain Name Registrant For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant’s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as “Applicant” for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN by: 1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar; 2. Communicating directly with the Domain Name Registrant using an address, email, or telephone number provided by the Domain Name Registrar; 3. Communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS record’s “registrant”, “technical”, or “administrative” field; 4. Communicating with the Domain’s administrator using an email address created by pre-pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN; 5. Relying upon a Domain Authorization Document; 6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN; or 7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described. Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.3 https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf
  - smt88 12y ago
    Again, email addresses are fine, but which email address is important. The address on the WHOIS record isn't bad, as long as that's disclosed to the certificate purchaser ahead of time. TXT records and uploading files are definitely better, though.
  - ivanr 12y ago
    If you're going to change your messages after posting them, at least disclose that you did so. Some of the replies don't make sense with the new content you added.
- deleted 12y ago
  [deleted]
mdewinter 12y ago
Do note that you need TLSv1.2 to connect to the website, or plain HTTP.
- yuhong 12y ago
  They even made the site AES-256 only, even though Chrome and Firefox don't do AES-256-GCM.
tbrownaw 12y ago
Of all the CAs my browser trusts, any single one of them can compromise the entire web by fucking up and issuing bad certificates. I have no say in which CAs I "trust", since my list has to match the list that site owners pick from. Site owners have no benefit from picking better CAs on the list over worse CAs also on the list, because my browser trusts them the same. How could anyone think this is a good system!? [Edit: and yeah, things like cert pinning can mitigate the damage a bit. That's not enough to make a bad idea suddenly a good idea, and it only took approximately forever to start being implemented.]
- dragonwriter 12y ago
  If users had and at least some exercised control over trusted CAs, at least to the extent of disabling if not adding, then site owners should have an incentive to choose better CAs, since worse CAs would be disabled by security-conscious users.
- MichaelGG 12y ago
  The idea, as far as there is one, is that if a CA does fuck up for real, then they get revoked and are out of business. But the Comodo "let's trust resellers to validate" didn't have any impact (and I get 2-8 calls s week from em often). Browsers might consider showing the country of the registrar, in the UI. So if I ever connect to a Canadian or US domain, and the registrar is some totally unrelated country, I could be alarmed. OTOH this might just end up confusing people even more.
nailer 12y ago
This exact attack was used on obtain a certificate for login.live.com, Microsoft's single sign on site used by millions of people, in 2008 by Mike Zusman. See https://books.google.co.uk/books?id=fQOLBAAAQBAJ&pg=PA88&lpg=PA88&dq=login.live.com+mike+zusman&source=bl&ots=sFdqVRylJ4&sig=21jZ5C4rGZ_eMtX8dt-Myzwhoks&hl=en&sa=X&ei=rooNVaefCsieywOh5IGQCg&ved=0CCgQ6AEwBA https://books.google.co.uk/books?id=fQOLBAAAQBAJ&pg=PA88&lpg... Domain validated SSL was always a bad idea. Disclaimer: I sell EV SSL validation.
- deleted 12y ago
  [deleted]
- mukyu 12y ago
  It was also used to get a live.fi certificate like a week ago. [1] [1] http://arstechnica.com/security/2015/03/bogus-ssl-certificate-for-windows-live-could-allow-man-in-the-middle-hacks/ http://arstechnica.com/security/2015/03/bogus-ssl-certificat...
- driverdan 12y ago
  > Domain validated SSL was always a bad idea. I strongly disagree. We need to move towards using TLS everywhere and part of doing that is making it easy for everyone to get a cert. You can validate domain control through DNS / whois records instead of the standard group of admin email address.
  - nailer 12y ago
    Sure, but there are no rules requiring that, which means browsers must treat all DV certs as the lowest common denominator.
- cesarb 12y ago
  > Domain validated SSL was always a bad idea. It's more like the way domain ownership is validated is awful. If the only way to validate domain ownership was to ask the domain owner to create a TXT entry, with both the entry name and its contents being nonces chosen by the certificate authority, it would be much harder to do these attacks (one would have to be able to MITM between the certificate authority and the domain's DNS servers, or compromise the DNS servers).
joosters 12y ago
Is there any way to discover a list of SSL certs that have been issued for a domain? The problem here is, once someone has shown that they could receive emails for administrator@yourdomainname, you have no idea how many SSL certificates they bought, and from which CAs. Even if they publish a blog post about it and show you a certificate, surely your domain is now compromised? You can revoke that certificate, but how do you know that was the only one they obtained? From this point on, all you know is that your domain name is potentially compromised and there's nothing you can do to fix it...
- ivanr 12y ago
  No. Certificate Transparency [1] might eventually make it possible, but it's still early days. A much wider adoption is needed. [1] http://www.certificate-transparency.org/ http://www.certificate-transparency.org/
- vbezhenar 12y ago
  Public Key Pinning could help for users running compliant browsers.
agwa 12y ago
Disclosing the private key in this blog post was extremely irresponsible. Although the certificate has been revoked, revocation basically doesn't work[1], so for practical purposes this key will usable for MitM until it expires on Mar 19, 2016. Hopefully browser vendors will push out updates that explicitly blacklist it (Chrome is pretty proactive about this, not sure about other browsers), but that won't help non-browser clients or users running out-of-date browsers. If you ever do this, please, please destroy the private key immediately. There are other ways to prove you had possession of it, such as by signing something with it. [1] https://www.imperialviolet.org/2014/04/29/revocationagain.html https://www.imperialviolet.org/2014/04/29/revocationagain.ht...
- ivanr 12y ago
  Indeed. Hopefully browser vendors will consider this certificate for explicit blacklisting using their proprietary channels. (I've already asked.)
  - utefan001 12y ago
    Does anyone know if there is a way to blacklist a certificate on a windows 8.1 machine? To me, managing certificates between the os, IE, Chrome and Firefox is a bit of a joke in 2015. Besides blacklisting, I would love to know of script that will output the certificates that the PC has trusted but are not trusted by Verisign.
    - realityking 12y ago
      Both Internet Explorer and Chrome use the system's certificate store. So you "only" have to manage the os and Firefox.
  - agl 12y ago
    Done in Chrome with CRLSet 2140.
- mdewinter 12y ago
  Then shouldn't revocation be fixed?
rgj 12y ago
When another Dutch ISP launched in 1998, I was able to register the root@ email address and a friend of mine got info@. It took them over one year to figure out that they might want to take those away from us. Surprising to hear that this is still possible all those years later, especially with an ISP like xs4all.nl. Those guys always had a good reputation, security-wise. I see they still have the tradition that you get an apple pie for responsible disclosure (https://www.xs4all.nl/over-xs4all/beleid/responsibledisclosure/ https://www.xs4all.nl/over-xs4all/beleid/responsibledisclosu...). So bon appetit!
- jacquesm 12y ago
  The days of Rop, Paul and Cor are long gone. XS4ALL got bought by KPN and that was the end of that.
witty_username 12y ago
surely Comodo can check if there is an existing cert?
- shabble 12y ago
  there's no reason having a cert should prevent you from registering another one, afaik. There are plenty of reasons you might legitimately want to do that, and running the certpatrol firefox extension shows that lots of sites change cert (and even issuer CA) fairly regularly.
  - PhantomGremlin 12y ago
    > running the certpatrol firefox extension shows that lots of sites change cert (and even issuer CA) fairly regularly Everyone who wants to venture an opinion on how to "fix" certificates should first run Certificate Patrol for a while. The real world is pretty messy.
agl 12y ago
I'm looking into a CRLSet push to block this certificate in Chrome now.
- agl 12y ago
  CRLSet 2140 contains a public-key block for this. If you're on desktop Chrome you can go to chrome://components and check for a CRLSet update manually. If you're testing it, note that Chrome caches certificate validity results for a while so you might need to restart Chrome to see the effect.
est 12y ago
The most mind boggling aspect of PKI is that certs for a CN is not globally exclusive. Hell even something as broken as DNS has one and only one place to find each domain's authoritative SOA record
lucio 12y ago
What happens if you try admin@xxx using an unicode homoglyph, i.e, the letter "a" in "admin" being the Cyrillic letter "а", U+0430 instead of U+0061 ?
- dylz 12y ago
  Many email systems don't exactly support unicode usernames in the first place, and provisioning systems will just send to administrator@ ([a-z]). It's not "enter your own email", you just get to pick from a variety of emails to provision a cert like admin@, ssladmin@, postmaster@, and the whois email.
hackhat 12y ago
Imo the problem is of the issuer. They only opens holes by doing this kind of things. Imagine if you already secured the admin@domain.com and tomorrow the issuer thinks that admin-ssl@domain.com could be used for validation. Now what, you should keep up with their updates every hour?
deleted 12y ago
[deleted]
bandrami 12y ago
This is why self-signed certificates are more secure than CA-signed certificates. When you expand the trust model to include three parties rather than two, it gets much more complex and vulnerable. If I see a self-signed certificate from CitiBank, I know that the counterparty claims to be CitiBank. That's all I know. When I receive a Verisign-signed certificate from CitiBank, I know a party claiming to be Verisign claims that the counterparty is CitiBank. That doesn't realistically help me much.

68 points by mdewinter 12y ago

smt88 12y ago

I've never seen a provider of SSL certificates (or any other service) allow you to "prove ownership" of a domain by receiving an email. Even from the early days of email, it has never been the case that a majority of a domain's email addresses were assigned to owners of the entity. That is just absolutely insane.

justinsb 12y ago
Proving ownership by sending email to the contacts in the WHOIS record is the _only_ way I've seen for the cheapest certificates. What other ways are you thinking of, and can you point to any CAs that do them (for their cheapest certificates)?
- smt88 12y ago
  I have no problem with that, but that's not what happened in the article.
  - stephenr 12y ago
    Where does it say that isnt what happened? It's entirely possible the WHOIS data for the domain in question had several email addresses listed, at least one of which was not blacklisted for use by clients.
- ams6110 12y ago
  Years ago you had to do things like fax an approval letter printed on company letterhead.
  - toast0 12y ago
    Whenever we need something on leterheas, our GC makes up letterhead on the spot using images on our media resources page.
patio11 12y ago
I think it's Old Webmaster Lore that there exist roughly ten email addresses which are Widely Considered To Be Special. abuse@, postmaster@, and administrator@ are three of them. There exist a lot of systems in the world which rely on this being true, irrespective of whether it is in fact true.
- tomjen3 12y ago
  I seem to recall DNS being one of them, that is that you have to have somebody monitor abuse@. But either way, this is yet another reason to ditch certificates: it is way too fragile a system (not the least because it gives users the "it has a lock, it means it is safe").
- helper 12y ago
  Is the rest of the list you are thinking of RFC2142?[1] [1]: https://www.ietf.org/rfc/rfc2142.txt https://www.ietf.org/rfc/rfc2142.txt
mukyu 12y ago
Email is an incredibly common method for domain validated certificates. The other common options are a TXT/CNAME record or uploading a specific file to a certain URL. The requirements for domain validation are: 11.1.1 Authorization by Domain Name Registrant For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant’s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as “Applicant” for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN by: 1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar; 2. Communicating directly with the Domain Name Registrant using an address, email, or telephone number provided by the Domain Name Registrar; 3. Communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS record’s “registrant”, “technical”, or “administrative” field; 4. Communicating with the Domain’s administrator using an email address created by pre-pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN; 5. Relying upon a Domain Authorization Document; 6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN; or 7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described. Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.3 https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf
- smt88 12y ago
  Again, email addresses are fine, but which email address is important. The address on the WHOIS record isn't bad, as long as that's disclosed to the certificate purchaser ahead of time. TXT records and uploading files are definitely better, though.
- ivanr 12y ago
  If you're going to change your messages after posting them, at least disclose that you did so. Some of the replies don't make sense with the new content you added.
deleted 12y ago
[deleted]

mdewinter 12y ago

Do note that you need TLSv1.2 to connect to the website, or plain HTTP.

yuhong 12y ago
They even made the site AES-256 only, even though Chrome and Firefox don't do AES-256-GCM.

tbrownaw 12y ago

Of all the CAs my browser trusts, any single one of them can compromise the entire web by fucking up and issuing bad certificates. I have no say in which CAs I "trust", since my list has to match the list that site owners pick from. Site owners have no benefit from picking better CAs on the list over worse CAs also on the list, because my browser trusts them the same. How could anyone think this is a good system!? [Edit: and yeah, things like cert pinning can mitigate the damage a bit. That's not enough to make a bad idea suddenly a good idea, and it only took approximately forever to start being implemented.]

dragonwriter 12y ago
If users had and at least some exercised control over trusted CAs, at least to the extent of disabling if not adding, then site owners should have an incentive to choose better CAs, since worse CAs would be disabled by security-conscious users.
MichaelGG 12y ago
The idea, as far as there is one, is that if a CA does fuck up for real, then they get revoked and are out of business. But the Comodo "let's trust resellers to validate" didn't have any impact (and I get 2-8 calls s week from em often). Browsers might consider showing the country of the registrar, in the UI. So if I ever connect to a Canadian or US domain, and the registrar is some totally unrelated country, I could be alarmed. OTOH this might just end up confusing people even more.

nailer 12y ago

This exact attack was used on obtain a certificate for login.live.com, Microsoft's single sign on site used by millions of people, in 2008 by Mike Zusman. See https://books.google.co.uk/books?id=fQOLBAAAQBAJ&pg=PA88&lpg=PA88&dq=login.live.com+mike+zusman&source=bl&ots=sFdqVRylJ4&sig=21jZ5C4rGZ_eMtX8dt-Myzwhoks&hl=en&sa=X&ei=rooNVaefCsieywOh5IGQCg&ved=0CCgQ6AEwBA https://books.google.co.uk/books?id=fQOLBAAAQBAJ&pg=PA88&lpg... Domain validated SSL was always a bad idea. Disclaimer: I sell EV SSL validation.

deleted 12y ago
[deleted]
mukyu 12y ago
It was also used to get a live.fi certificate like a week ago. [1] [1] http://arstechnica.com/security/2015/03/bogus-ssl-certificate-for-windows-live-could-allow-man-in-the-middle-hacks/ http://arstechnica.com/security/2015/03/bogus-ssl-certificat...
driverdan 12y ago
> Domain validated SSL was always a bad idea. I strongly disagree. We need to move towards using TLS everywhere and part of doing that is making it easy for everyone to get a cert. You can validate domain control through DNS / whois records instead of the standard group of admin email address.
- nailer 12y ago
  Sure, but there are no rules requiring that, which means browsers must treat all DV certs as the lowest common denominator.
cesarb 12y ago
> Domain validated SSL was always a bad idea. It's more like the way domain ownership is validated is awful. If the only way to validate domain ownership was to ask the domain owner to create a TXT entry, with both the entry name and its contents being nonces chosen by the certificate authority, it would be much harder to do these attacks (one would have to be able to MITM between the certificate authority and the domain's DNS servers, or compromise the DNS servers).

joosters 12y ago

Is there any way to discover a list of SSL certs that have been issued for a domain? The problem here is, once someone has shown that they could receive emails for administrator@yourdomainname, you have no idea how many SSL certificates they bought, and from which CAs. Even if they publish a blog post about it and show you a certificate, surely your domain is now compromised? You can revoke that certificate, but how do you know that was the only one they obtained? From this point on, all you know is that your domain name is potentially compromised and there's nothing you can do to fix it...

ivanr 12y ago
No. Certificate Transparency [1] might eventually make it possible, but it's still early days. A much wider adoption is needed. [1] http://www.certificate-transparency.org/ http://www.certificate-transparency.org/
vbezhenar 12y ago
Public Key Pinning could help for users running compliant browsers.

agwa 12y ago

Disclosing the private key in this blog post was extremely irresponsible. Although the certificate has been revoked, revocation basically doesn't work[1], so for practical purposes this key will usable for MitM until it expires on Mar 19, 2016. Hopefully browser vendors will push out updates that explicitly blacklist it (Chrome is pretty proactive about this, not sure about other browsers), but that won't help non-browser clients or users running out-of-date browsers. If you ever do this, please, please destroy the private key immediately. There are other ways to prove you had possession of it, such as by signing something with it. [1] https://www.imperialviolet.org/2014/04/29/revocationagain.html https://www.imperialviolet.org/2014/04/29/revocationagain.ht...

ivanr 12y ago
Indeed. Hopefully browser vendors will consider this certificate for explicit blacklisting using their proprietary channels. (I've already asked.)
- utefan001 12y ago
  Does anyone know if there is a way to blacklist a certificate on a windows 8.1 machine? To me, managing certificates between the os, IE, Chrome and Firefox is a bit of a joke in 2015. Besides blacklisting, I would love to know of script that will output the certificates that the PC has trusted but are not trusted by Verisign.
  - realityking 12y ago
    Both Internet Explorer and Chrome use the system's certificate store. So you "only" have to manage the os and Firefox.
- agl 12y ago
  Done in Chrome with CRLSet 2140.
mdewinter 12y ago
Then shouldn't revocation be fixed?

rgj 12y ago

When another Dutch ISP launched in 1998, I was able to register the root@ email address and a friend of mine got info@. It took them over one year to figure out that they might want to take those away from us. Surprising to hear that this is still possible all those years later, especially with an ISP like xs4all.nl. Those guys always had a good reputation, security-wise. I see they still have the tradition that you get an apple pie for responsible disclosure (https://www.xs4all.nl/over-xs4all/beleid/responsibledisclosure/ https://www.xs4all.nl/over-xs4all/beleid/responsibledisclosu...). So bon appetit!

jacquesm 12y ago
The days of Rop, Paul and Cor are long gone. XS4ALL got bought by KPN and that was the end of that.

witty_username 12y ago

surely Comodo can check if there is an existing cert?

shabble 12y ago
there's no reason having a cert should prevent you from registering another one, afaik. There are plenty of reasons you might legitimately want to do that, and running the certpatrol firefox extension shows that lots of sites change cert (and even issuer CA) fairly regularly.
- PhantomGremlin 12y ago
  > running the certpatrol firefox extension shows that lots of sites change cert (and even issuer CA) fairly regularly Everyone who wants to venture an opinion on how to "fix" certificates should first run Certificate Patrol for a while. The real world is pretty messy.

agl 12y ago

I'm looking into a CRLSet push to block this certificate in Chrome now.

agl 12y ago
CRLSet 2140 contains a public-key block for this. If you're on desktop Chrome you can go to chrome://components and check for a CRLSet update manually. If you're testing it, note that Chrome caches certificate validity results for a while so you might need to restart Chrome to see the effect.

est 12y ago

The most mind boggling aspect of PKI is that certs for a CN is not globally exclusive. Hell even something as broken as DNS has one and only one place to find each domain's authoritative SOA record

lucio 12y ago

What happens if you try admin@xxx using an unicode homoglyph, i.e, the letter "a" in "admin" being the Cyrillic letter "а", U+0430 instead of U+0061 ?

dylz 12y ago
Many email systems don't exactly support unicode usernames in the first place, and provisioning systems will just send to administrator@ ([a-z]). It's not "enter your own email", you just get to pick from a variety of emails to provision a cert like admin@, ssladmin@, postmaster@, and the whois email.

hackhat 12y ago

Imo the problem is of the issuer. They only opens holes by doing this kind of things. Imagine if you already secured the admin@domain.com and tomorrow the issuer thinks that admin-ssl@domain.com could be used for validation. Now what, you should keep up with their updates every hour?

deleted 12y ago

[deleted]

bandrami 12y ago

This is why self-signed certificates are more secure than CA-signed certificates. When you expand the trust model to include three parties rather than two, it gets much more complex and vulnerable. If I see a self-signed certificate from CitiBank, I know that the counterparty claims to be CitiBank. That's all I know. When I receive a Verisign-signed certificate from CitiBank, I know a party claiming to be Verisign claims that the counterparty is CitiBank. That doesn't realistically help me much.