How I got a valid SSL certificate for my ISP's main domain
raymii.org
raymii.org
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.ht...
But you can't do revocation that way. The client can get the certificate from the server being certified, but it can't get a revocation that way because nothing forces the server provide the revocation.
To do revocation you have to have a database of all the revoked certificates and check every certificate against the database before accepting it. But there are too many revoked certificates to store on the client; the database is too big. And if the client has to query some server then the attacker can DoS or MITM that server.
The best way to handle "revocation" is to fully automate certificate issuance like Let's Encrypt, but then only issue certificates for a short period of time, like 10 days (but renewed every 7). Then you don't have to worry about revocation because the certificate expires in about the same amount of time it would take to be detected and distributed in a revocation database.
Instead of having a monolithic CRL, the CA publishes smaller CRLs and writes the CRL location on which a certificate would appear if revoked in the certificate itself.
In other words, every X certificates, the CA creates a new CDP, call it CDP_n, and all subsequent certificates issued between now and +X from now have the location of CDP_n written in them: That's where you look for their CRL.
+X certificates from now, the CA creates CDP_n+1 and starts writing that into the certs.
The size of X can be set, tuned, based on certificate lifetimes, number of users, etc., etc. If you want your CRLs to be fresher, use a smaller X, have more CDPs.
The other nice thing about the CDP is that it ties the CRL retrieved from wherever (an LDAP repo, a web site, etc.) to the certificate: The certificate contains within its signed payload a reference to the CDP location and the CRL contains within its signed payload a reference to the same location (the issuingDistributionPoint) so you have a high integrity check that the CRL being used to verify the certificate is actually the right one, even if the certificate is valid and therefore not listed thereupon.
This prevents an attacker from fooling you into trusting a revoked certificate by replacing its CRL with one that doesn't match it: The replacement CRL will have the wrong iDP, one that does not correspond to the CDP in the cert.
That's essentially the situation we're in with OCSP stapling, if you consider the certificate plus OCSP response to be the certificate. (The "must staple" cert extension[1] would make it even more similar.)
[1] https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeatur...
You validate yourself in the usual way and present a CSR to the CA. The CA signs the certificate but only with a very short expiration. However, unless the certificate is "revoked", you can come back at any point and the CA will automatically sign an identical certificate with the sole exception of the expiration date. (Then maybe they stop after e.g. two years unless you validate again, to keep an "actual" expiration.)
The advantage of that over OCSP stapling is that it requires zero modification to the client. What advantage does OCSP stapling have over that?
That can make it less likely that your certs will be used in revocation attacks. It does absolutely nothing to protect your visitors from other compromised certificates.
The "best" known way (to my knowledge) is to use a blockchain, which doesn't have the revocation problem.
Here is a comparison of a blockchain-based approach I'm working on with some other folks called DNSChain to other approaches people have suggested:
https://github.com/okTurtles/dnschain/blob/master/docs/Compa...
"The RDATA field in the DNS protocol may only hold data of size 65535 octets (64kb) or less. This means that each CERT RR MUST NOT contain more than 64kb of payload, even if the corresponding certificate or certificate revocation list is larger. This document addresses this by defining "indirect" data types for each normal type."
Domain validated SSL was always a bad idea. Disclaimer: I sell EV SSL validation.
[1] http://arstechnica.com/security/2015/03/bogus-ssl-certificat...
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.
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).
On the other hand, being able to modify the DNS records is a much stronger proof of ownership.
The linked post talks of phone verification, but we know GSM networks don't use strong cryptography and stationary phones aren't better secured either. Do you perform any additional verification? I'd want to see use of government issued personal certs for this purpose, surprised even that this isn't commonplace.
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.]
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.
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/responsibledisclosu...). So bon appetit!
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...
Hell even something as broken as DNS has one and only one place to find each domain's authoritative SOA record
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.
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.
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.
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.
There exist a lot of systems in the world which rely on this being true, irrespective of whether it is in fact true.
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").
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
TXT records and uploading files are definitely better, though.
I'd also guess there are plenty of domains depending on CA validation that haven't enabled DNSSEC.