Hacker News Reader

Comment by nothrabannosir | Hacker News Reader

That's just one project, and it doesn't even exist yet.

The web is moving faster every day, apparently. I sure do hope that project will be all it's chalked up to be.

For example, I need IP-only certs for a new project I'm working on (waiting for DNS to propagate to all clients is too unreliable and slow). If letsencrypt doesn't do that... well then I'd have to hope real hard for a competent CA out there who has an automated process available that allows IP-only certs. And whatever their price, if companies start following Mozilla's lead too soon, I'll have to pay up.

The wording in the article is perhaps not so damning yet, but it's still making me uneasy that they put out this press release while there are currently ZERO viable solutions for this.

View on HN

For example, I need IP-only certs for a new project I'm working on (waiting for DNS to propagate to all clients is too unreliable and slow).

This doesn't make any sense. You're not waiting for DNS to propagate to clients; if anything you're waiting for recursive DNS servers at shitty ISPs to time out their caches when they are configured to not honor the RR's TTL sent by the authoritative server in a misguided attempt to make the internet "faster".

But this is completely avoidable without having to use IPs or certificates with CN/SAN that are IPs: get a wildcard cert and rotate the subdomain name. It's a new hostname, so it busts intermediate DNS caches by being new queries; since it's a new query, there's no "propagation to clients" to wait for when you change IPs, all queries for the new name hit authoritative servers. Additionally, it looks infinitely more legit than a website that is accessible only via IP address. And doubly additionally, if you're going through so many IPs, presumably you'll be rotating some out and those may be assigned to other people who can then get their own cert for that IP and impersonate you.

How often are DNS caches configured to ignore TTLs? That sounds awful.

I assumed the grandparent simply didn't understand the need to lower his TTLs.

Google DNS seems to ignore TTL but it does the opposite of what the GP is saying; gDNS drops it cache before the TTL is expired.

Unless you have a reference for Google saying they purposely do this, it is more likely that the cache is dropping LRU entries as it fills up. Also, I doubt there is a trivial number of actual resolvers behind the google public DNS endpoints, so you may be seeing the result of multiple individual servers without shared cache initially populating their caches.

Some quick tests with dig seem to indicate that, at least for the region I'm in, my queries to google's public DNS is rotating between 4 or 5 servers, as evidenced by the TTLs being returned.

It is awful. It makes the standard way to plan and do a DNS migration really difficult.

It occurred rarely, but a few years ago it was a regular problem because some bigger ISPs were doing it[0]. Not sure how common it is these days.

That being said, I'm having troubling coming up with a project that would be better served with IP addresses than a constant name, so I have no idea what the OP I was responding to could be doing that that problem needed to be addressed at all.

[0] https://www.google.com/search?q=isp+ignore+dns+ttl

LetsEncrypt works with IPv4. I assume it will work with IPv6. LetsEncrypt is a Mozilla project, it's safe to assume they will launch LetsEncrypt before deprecating non-secure websites.

Right now the subject identifier in a Let's Encrypt cert must be a DNS name, not an IP address. From the ACME protocol specification draft:

"Note that while ACME is defined with enough flexibility to handle different types of identifiers in principle, the primary use case addressed by this document is the case where domain names are used as identifiers. For example, all of the identifier validation challenges described in Section {identifier-validation-challenges} below address validation of domain names. The use of ACME for other protocols will require further specification, in order to describe how these identifiers are encoded in the protocol, and what types of validation challenges the server might require."

This is in line with other CAs - no certificates should be issued for IP addresses or internal server names with expiry dates after November 2015. See for example: https://www.digicert.com/internal-names.htm

Technically I think the requirement Digicert is referring to only forbids issuance for "reserved" IP addresses.

https://cabforum.org/internal-names/

The PDF document defines "Reserved IP Address" as "An IPv4 or IPv6 address that the IANA has marked as reserved".

Missed that, thanks!

Let's Encrypt does exist.

I watched a demo where they went from a vanilla apache install to an A scoring HTTPS site in sub 5 minutes at Libreplanet. It's a good idea to publicize the upcoming LARGE change.

I'm the person who gave that demo and I appreciate the compliment, but I'll readily admit that we can't yet issue publicly-trusted certificates to the public. So we aren't up and running in a way that a site could take advantage of.

On the other hand, our infrastructure, partnerships, and technology are very real. I hope they'll make the process just as easy as what you saw for many people soon.

StartSSL exists right now - and has been providing free certs for personal use for years now.

I'm curious about your requirement for IP only certs? Sure you don't "own" a domain name, but it's even less true that you "own" a specific IP address. (Well, at least for me, perhaps if your project is in the datacenter/isp/network-infrastructure space you might actually have some cintractual "ownership" of an IP address?)

StartSSL is far from simple to use.

It's hardly rocket surgery though.

Anyone incapable of following the steps required there is probably not who you'd want implementing your web server security…

Last time I tried, their site had JavaScript bugs and their email validation procedure didn't pass greylisting. I didn't want to place my web server security in the hands of a company with such low quality standards.

i had that problem when i used to run my own mail server (3 years ago). When did you last try?

It was less than a year ago, also running our own mail server.

That's the entire point. If the whole web is going to be secure, then someone who "is not who you'd want implementing your web server security" needs to be able to make it work, and work right.

I believe let's encrypt is supposed to be a single command to run. Anyone that can set up a webserver can manage it.

If you're going the minimally technical route then you're using shared or managed hosting and it's not your job to set up the SSL.

Well, the counter argument is that even if the whole population is going to not have brain tumours - I _still_ don't want "someone who's not a rocket surgeon" doing brain surgery.

Crypto is non-trivial. There'll never be a proper "Click this button to automatically secure your random php app running in cPanel/Plesk".

The best we'll see I suspect is a "click here and make your website pass the minimal checks modern browsers use to determine if you're secure", then we'll have a daily stream of site owners claiming "the PII/password/creditcard breach wasn't my fault - I used 2048 bit encryption!"

Reply on news.ycombinator.com