Hacker News new | past | comments | ask | show | jobs | submit login

Wait, what? httpS with a raw IP address. Where does the TLS certificate come from?

Curl has the same complaint that I do:

    $ curl https://192.0.32.9/domain/root.zone
    curl: (60) SSL: no alternative certificate subject name matches target host name '192.0.32.9'



The IP address for that FTP (and now HTTP) server changed so infrequently over the years, on the order of decades, that in the past IANA/ICANN published advance notice to the public before changing it. (A non-DNS way of changing an IP address.) It is probably hardcoded into lots of DNS software as this address is where root.hints is served. This is how ICANN DNS is boostrapped. From a single IP address. There are a few IP addresses I have memorised, 198.41.0.4, 192.5.6.30 and this one. Yes, I still use FTP to fetch the root.zone.

In the days of ye olde internet it used to be called "ftp.internic.net". Today, I believe it is still "internicftp.vip.icann.org".

To make curl work

   curl -k https://192.0.32.9 
or

   curl https://www.internic.net/domain/root.zone
I use curl in examples on HN because so many paople love it but TBH it is not a program I use myself. I use custom programs I wrote for doing HTTP requests. Finer controls than curl.


The certificate is issued to internic.net, www.internic.net, ftp.internic.net, wdprs.internic.net, and reports.internic.net

The IP address isn't directly validated, but you get something even better.


What is the better thing that we get.


Proof that it's internic.net is much better than proof of IP address.


How is it much better. I am honestly curious about the answer.


You can verify it with less preexisting knowledge, and it gives you much more confidence that you're in the right place to see a signed certificate for "internic.net" than to see a signed certificate for "yes this is the IP you typed, hope you typed the right one".

And it can't go out of date as easily. Like you said, the IP changes sometimes. internic.net doesn't change.


I have the IP address memorised. Is that what you mean by "preexisting knowledge". How does a certificate give me more confidence that I am in the right place. ICANN could choose any name it wants for this IP address. It might cease to use "www.internic.net". That name is only a CNAME at this point. If I look up the actual name "internicwww.vip.icann.org" it does not even return this IP address. It returns 192.0.47.9. Both addresses serve via FTP as well as HTTP. The only thing that gives me confidence that 192.0.32.9 is still the "right" address is 1. it is in a block that remains registered to ICANN and 2. the server continues to offer root.zone, arpa.zone and root.hints.

Am I understanding this correctly. You are concerned that the IP address might change. As I said, if that happened, they would not change it without notifying the public in advance. This IP address is used to bootstrap DNS. Thus, no one should need DNS to find it. AFAIK, outside of EV certificates, CAs rely on domain name registration as their "verification" mechanism. Seems like one has to trust the DNS in order to trust a CA. And why trust a CA.

I am quite certain I will be dead before this IP address ever changes again. It used to be 208.77.188.26. This is going to be the "right" IP address for the forseeable future. TLS cert or not. I use FTP to get the root.zone, not TLS. Verisign's zone file access program used to offer .com and .net zone files only via FTP. Even if you can use TLS to get them now, I'll bet you can still use FTP.


> How does a certificate give me more confidence that I am in the right place.

> Seems like one has to trust the DNS in order to trust a CA. And why trust a CA.

You're arguing that certificates are useless?

They're not, because you might be on a hostile network, and it's much easier to attack one person than to attack domain verification.

And even if certificates are 99% useless, that doesn't affect my argument about which kind of certificate is better.

> You are concerned that the IP address might change.

That was only one of the things I said. Other than hostile networks, you might make a typo, and there are various reasons you might not notice getting the wrong file immediately that a nice verifiable "internic.net" label could help with.


I never said certificates are "useless". I am commenting only on this one IP address and one specific use of it, downloading zone files. How do you extrapolate that to be a general statement about certificates.

In this case you are downlaoding a file that is served at a number of other known, unchanging IP addresses, "root servers." Even more, the RRs in the file have been signed, "DNSSEC".

All I am saying is that a "bare IP address" in this case is still useful, even without a domain name and certificate.


> I never said certificates are "useless". I am commenting only on this one IP address and one specific use of it, downloading zone files.

I meant useless in this scenario. So same.

> All I am saying is that a "bare IP address" in this case is still useful, even without a domain name and certificate.

What? Then we don't disagree at all. You need to reread my earlier comments. I said a certificate with a name is better than a certificate with an IP. I never said anything about the value of the IP address itself, only what's validated.


"I said a certificate with a name is better than a certificate with an IP."

I think that's debatable. IMO, it depends in part on the perceived value of the ICANN "domain name business" as some sort of vetting mechanism. In this case the party being vetted is ICANN itself. Although they did pay for "EV".

https://censys.io/ipv4/192.0.32.9/raw

Does Globalsign still offer certificates that are tied to IP addresses.

https://support.globalsign.com/customer/portal/articles/1216...

Here is a question for the TLS certificate fanatics: Why do CAs provide non-http URLs to their CA certificates in the certificates they sell. For example,

http://cacerts.digicert.com/DigiCertTLSRSASHA2562020CA1.crt

I suspect it is a bootstrapping issue. At the top of the chain there is some notion of implict trust. No different than with DNS. Trust should be decided by the end user not by developers, nor by some self-appointed "authority".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: