Not enough. You have to check the certificate's fingerprint, along with its validity.
TLS is not a silver bullet. If an attacker controls the host behind what everyone believes to be 1.1.1.1, nothing is to prevent them from applying for a legit certificate.
* They need to do that, and get the resulting certificate, and install it, during the attack. The weirder the product (and certificates for IP addresses are relatively weird) the more humans end up involved in your order, and humans are slow.
* This leaves a smoking gun in the Certificate Transparency logs. So we all get to know (in maximum 24 hours but usually the reality will be minutes) about this extra certificate.
1) would take about 20 seconds, thanks to Let's Encrypt, but probably only marginally more time for some other CA with an API.
2) Who exactly is staring at CT logs and going "oh, I don't remember this domain using this CA, maybe I should investigate this" ? Sure there's a record of it. Doesn't really matter during an attack, because public attacks like this aren't intended to last long.
All you need is a half hour or less to steal a couple hundred million from a bank, or cryptocurrency wallet, using this attack. That's more than enough incentive for most unscrupulous 3rd world hackers.
If you're an authoritarian government, you could require CAs in your country to selectively quiet CT logs by certain users, and just issue certs willy-nilly for your private government org for MITM purposes. Google Chrome would detect them for Google-owned properties, but smaller sites would never know. And spy agencies can use this at their leisure and basically never be held accountable, because world politics.
Let's face it. The CA system is a joke and BGP is the butt of it.
"would take about 20 seconds, thanks to Let's Encrypt"
Let's Encrypt does not offer certificates for IP addresses. They choose only to offer DV certificates using methods 3.2.2.4.6 and 3.2.2.4.7
How much of your hypothetical half hour will you spend trying to figure out why your chosen ACME client reports "Policy forbids issuance" when asked for an IP address?
As to who is staring at CT logs, well there's the fun thing about the design of CT, the _logs_ aren't where you would be staring, you would be looking at a _monitor_ and a monitor can be configured to do whatever it so happens you think is important. We know that commercial CAs already sell monitoring as part of "Enterprise security" type offerings.
Facebook took... I want to say minutes here, but I can't find an exact timeline, to spot that a certificate had been issued by Let's Encrypt for a name in their DNS hierarchy and begin investigating what went wrong.
Certificate Transparency isn't finished. As it stands today your authoritarian government "only" needs to ensure that nobody notices these shenanigans as unavoidably they create a "smoking gun" which would lead to their pet CA being distrusted. That's a tall order, but certainly not impossible in the short term, or for attacks in which the bogus certs are shown to a small number of individual targets rather than a broad population that will invariably notice by accident.
But longer term CT is intended for use with a gossip protocol so that it's impossible for the pretence to be kept up. Sooner or later a node somewhere will end up realising that there's an inconsistency, either it has seen SCTs that weren't logged, or it has seen logs that aren't consistent with the logs other nodes see, either of which is a matter for distrust.
BGP has no relationship to the Web PKI, which is what I presume you're referring to by "the CA system". The relatively small number of parties interested in BGP have developed their own PKI to fit their needs.
BGP allows anyone to issue fake certs, so it does have a relationship to web PKI.
And sure, if you have a couple billion dollars, you can set up fancy infrastructure and response teams to monitor the whole web (that you are aware of, that participate in CT) for a strangely-issued cert.
Or you could just get a cert issued by the CA you normally use. In which case, now we have to track some kind of "customer number" per CA. If you use more than one CA (Google does) now you're tracking different customer numbers on different CAs. And all that has to be standardized.
Most of these "fixes" for web PKI's glaring holes are intended for large multinational corporations, or are optional, or specific to a particular browser, and don't address the main concern: _do not trust an IP address to be who it claims to be_.
No, you wouldn't use a "customer number". The usual approach taken for these genuinely concerned outfits goes like this:
1. Agree contractual terms with particular Certificate Authorities in which all certs for names in your hierarchy need explicit approval from your security people.
2. Set DNSSEC-secured CAA records for your names forbidding issuance by other Certificate Authorities.
This funnels requests from hypothetical bad guys into your security people, which is exactly what they don't want. It loses you the shiny capability to do "spur of the moment" issuance, but presumably if you want these sort of terms the phrase "spur of the moment" causes you to start writhing and clutching your throat anyway. Insider threats will usually be much _worse_ than outsiders.
As to things being "specific to a particular browser" we can't and don't want to be able to force, say, Microsoft and Apple to do things just because everybody else decided they're a good idea.
The same with the trust store programmes. I can't make Microsoft take this seriously, but Microsoft can't make me use their SChannel and associated trust store. Maybe you have a lot more pull with Microsoft than I do.
If we're in a world where the "easiest" way to get a bogus certificate is now to do global BGP hijack of an entire /24 then I think we're on the right track.
Ok ye the CA system isn't great, but as far as I'm aware, letsencrypt do DNS queries from multiple POPs, so that the route would have to propagate extremely widely to convince them to issue a cert.
A representative of LE commented on HN recently that they do not verify from multiple POPs. But even if they did, that would not stop this attack.
There are hundreds of CAs, and not all of them are going to verify from multiple POPs. You only need your attack to work on one CA for it to be effective against every client on the web.
Even if all CAs verified from multiple POPs (not likely) the attacker will just increase their attack to advertise from multiple ISPs/POPs. The attack is virtually the same, the only thing you need is more network access, which is not hard to get.
There aren't really "hundreds" of CAs in a sense that matters here.
Last time somebody insisted on this I actually counted, I forget the answer I got, but it's less than three figures.
You can get a bigger number if your idea of "effective against every client on the web" is "It works in Internet Explorer". Microsoft is very... liberal in accepting new CAs controlled by corporate or sovereign entities.
But if you expect "every client on the web" to include Chrome on Android phones, Safari on iPhones and Firefox everywhere, not just Internet Explorer, then you're talking about dozens, not hundreds, mostly because of the work done by Mozilla.
And most of those CAs are fairly small. Forget a nice API you can just make an HTTP request to and get your certificate in seconds, some of them are going to expect you to wait until business hours and talk to them on the telephone.
I don't enforce pinning but I do enforce checking the TLS hostname. I assume that's good enough what with certificate transparency, 100% works against a passive attack anyway?
I looked into pinning but the big services warn against it as they could change their certs at anytime, which is fair enough.
They'd have to convince a large enough percentage of the internet to accept their routes. Automated DNS services like letsencrypt make sure to take measurements from many places around the world to prevent things like this right?
TLS is not a silver bullet. If an attacker controls the host behind what everyone believes to be 1.1.1.1, nothing is to prevent them from applying for a legit certificate.