Let's Encrypt Rolls Out Free Security Certs For IP Addresses (theregister.com) 24
Let's Encrypt, a certificate authority (CA) known for its free TLS/SSL certificates, has begun issuing digital certificates for IP addresses. From a report: It's not the first CA to do so. PositiveSSL, Sectigo, and GeoTrust all offer TLS/SSL certificates for use with IP addresses, at prices ranging from $40 to $90 or so annually. But Let's Encrypt does so at no cost.
For those with a static IP address who want to host a website, an IP address certificate provides a way to offer visitors a secure connection with that numeric identifier while avoiding the nominal expense of a domain name.
For those with a static IP address who want to host a website, an IP address certificate provides a way to offer visitors a secure connection with that numeric identifier while avoiding the nominal expense of a domain name.
No place like home (Score:2)
Re: (Score:3)
Wait you need certs for that? Just who is it that you don't trust to snoop on your loopback network. ;-)
Re: (Score:2)
Nope, they're *mine*! I even have the T-shirt!
"There's no place like 127.0.0.1"
Whenever somebody tells me they think the shirt is funny, I accuse them of being a nerd.
What is the use case? (Score:2)
I don't understand the use case. If I connect via TCP to some IP address 42.42.42.42, it's rather difficult for an attacker to actually connect me to a different IP address... much more difficult than spoofing a domain name.
So, the certificate tells me "Yes, this really is 42.42.42.42." But I knew that already.
Maybe for UDP, attacks are a bit more feasible, but even so... they're not exactly easy.
I guess the only real use case I can see is to avoid a scary browser warning if you navigate to an IP ad
Re:What is the use case? (Score:4, Insightful)
Is it really?
Have you run a router or honeypot?
Re: (Score:2)
If an attacker can reroute traffic destined for a specific IP address, then they can also obtain a certificate for that IP address by running the ACME challenge. (Same for the ACME HTTP challenge, actually...)
The only way this would fail is if an attacker can reroute my traffic, but not the traffic needed for the ACME challenge.
Re: (Score:2)
Um, no.
Just because you can reroute any IP on networks you control doesn't mean you can do shit on networks outside your control.
For example... If i setup a free wifi and let people connect, i can reroute the web traffic to my webserver. But no, that doesn't help me getting a valid certificate whatsoever.
Re: (Score:2)
While I'm not sure of the technicalities which may prevent this I don't think that's quite right. If you can reroute traffic to your IP address then you can in theory also perform the necessary challenges in order to get the cert issued. IP address certs are not issued through a DNS challenge (obviously) as such no login or access to DNS management is required, only http-01 certification. So if you can re-route the IP to your machine for the purpose of spoofing you absolutely have the capability to respond
Re: (Score:3)
Different machines can respond to the same IP address as seen from the Internet vs. from a coffee shop's guest WLAN. Let's Encrypt sees only the former when evaluating an http-01 challenge. If you associate to a guest WLAN and connect to https://42.42.42.42/ [42.42.42.42] and it offers a certificate issued by Let's Encrypt, that means you're seeing the same server that Let's Encrypt saw through the Internet, not a server on the guest WLAN that's intercepting your connection.
Re: (Score:2)
OK, yes, the free Wifi scenario makes sense.
But I still think it's a bit weird to have proof of identity for IP addresses. For example, if a host presents a valid certificate for "example.com", then I can be reasonably confident that the host I'm talking to is controlled by whoever registered the domain "example.com", barring a compromised machine or leaked private key. There's a trail from the domain registrar to the name servers to the host.
But if someone tells me to visit 16.34.212.76 I have no ide
Re: (Score:3)
One of the key parts of ACME is that cert issuers are supposed to check the certificate from different points on the Internet, so that they have a good chance of seeing different answers if that kind of MitM attack happens. They won't necessarily know which is the true server response, but they will not issue a certificate if they see a mismatch.
Re: (Score:2)
Re: (Score:2)
I don't understand the use case.
Some things need to work when most everything on the network is broken. Think: out of band access to the DNS server (DRAC, ILO, IPMI).
So, the certificate tells me "Yes, this really is 42.42.42.42." But I knew that already.
No, you know that some machine out there responded to that IP address. You don't know whether it's the one you meant or, say, the hotel's captive portal.
Re: What is the use case? (Score:2)
None of those things you listed are open to the general public, so there is no reason not to use a self signed certificate.
Hard for users to trust a private CA (Score:2)
Other than that new versions of mainstream operating systems and web browsers make it harder for the owner of a device to trust the root certificate of a particular private CA. I seem to remember, for example, that iOS and Android put a scary warning on the lock screen if one or more user-trusted root certificates is installed, and Android application developers have to opt into user-trusted root certificates through a "Network Security Config".
Re: (Score:2)
You could say the same for a domain name.
In both cases the attack is to intercept your traffic and route you to another destination.
Re: (Score:3)
Anyone in between you and the server can potentially snoop on the data packets in transit, but it is far less likely that they can decypher it when you use SSL than with plain unencrypted HTTP. Yes, you can access a server by IP that uses an SSL cert assoc
Re: (Score:2)
The SSL cert doesn't "encrypt the traffic". It's solely used as proof of identity.
You can have proof of identity without encryption, and you can have encryption without proof of identity.
Re: (Score:2)
Most web-based software demands HTTPS nowadays. But not all (internal) servers/services are behind a domain name. Selfhosters sure are limited. And with selfhosters I mean the persons with their own server(s)/service(s) at home, not those renting a VPS. In that case a domain and proper DNS management is a given.
The environment I inherited still is bound to an ISP not willing to do (reverse) DNS correctly, HTTPS becomes a bit of a problem. No clue how the ISP doesn't do DNS correctly, because none of the met
Pandering to a bad habit (Score:2)
So this feature really is for old and stuck technologies and bad designs that are hard to change.
I'm glad they did. Bad designs deserve security too. But they deserve redesign more.
Re: (Score:2)
You can use IP address in your web browser, you don't have to type in a DNS location.
Re: (Score:2)
Agreed. It annoys me when IT departments tell you to access a resource by giving you an IP address. The whole point of DNS, is that IP addresses change. You don't want your website, or your security cert, to change just because for whatever reason, you need to move to a different IP address. Use DNS, it's there for a reason!
Re: Pandering to a bad habit (Score:2)
Really old and stuck technologies.... that require TLS and have up to date certificate authority lists. The root cert that lets encrypt uses has only existed since 2016