Live data from Hacker News

Why isn't HTTPS everywhere yet?

webappsec-test.info

41–50 of 130 posts

Re: Why isn't HTTPS everywhere yet?

#41

Earlier quoted context omitted.

No, you are incorrect. At the moment, their certs are cross-signed, and I have tested my site with multiple browsers. It works.

The cross sign is too far up the chain. If you cross sign a self-signed cert what do you get? A Let's Encrypt Cert. Domain Ownership is not the same as file ownership.

This does not make sense, I'm not sure what you're trying to say. The cross-sign works on all major browsers. Domain validation as practised by Let's Encrypt is in accordance with CA/B Baseline Requirements, and they're not the first CA to offer domain ownership verification via HTTP.

Re: Why isn't HTTPS everywhere yet?

#42
post #40

Something that no one has seemed to mention: it doesn't work on shared hosting, it requires a static IP. For small sites, the additional cost of moving to a plan that supports SSL and has a static IP, this could be a big cost.

It doesn't require a static IP; you can use SNI to use HTTPS on a shared IP:

https://en.wikipedia.org/wiki/Server_Name_Indication

SNI was already been mentioned an hour ago, too:

https://news.ycombinator.com/item?id=10928036

Re: Why isn't HTTPS everywhere yet?

#43
post #40

Something that no one has seemed to mention: it doesn't work on shared hosting, it requires a static IP. For small sites, the additional cost of moving to a plan that supports SSL and has a static IP, this could be a big cost.

Static IP? Do you mean "one certificate per IP, unless you're okay with not supporting clients that don't use SNI"?

Re: Why isn't HTTPS everywhere yet?

#44
post #42
post #40

Something that no one has seemed to mention: it doesn't work on shared hosting, it requires a static IP. For small sites, the additional cost of moving to a plan that supports SSL and has a static IP, this could be a big cost.

It doesn't require a static IP; you can use SNI to use HTTPS on a shared IP: https://en.wikipedia.org/wiki/Server_Name_Indication SNI was already been mentioned an hour ago, too: https://news.ycombinator.com/item?id=10928036

Interesting, I hadn't heard of that. Perhaps I should make a correction -- on the webhost my small business uses, purchasing a static IP is required for SSL support. I was under the impression this was a technical limitation, but I was apparently wrong.

Re: Why isn't HTTPS everywhere yet?

#45

Earlier quoted context omitted.

No, you are incorrect. At the moment, their certs are cross-signed, and I have tested my site with multiple browsers. It works.

The cross sign is too far up the chain. If you cross sign a self-signed cert what do you get? A Let's Encrypt Cert. Domain Ownership is not the same as file ownership.

Of course the cross signed cert works!

That not the point.

The cross signature is worthless if the signed cert beneath it is self-signed.

If Identrust cross signed self signed certs, the self signed cert would be trusted too... and it would "work" in all browsers...

Coly Tarry Frap Tarts! you're daft.

Here try this:

1. Setup a domain with an MX record that points off domain and a dmarc p=reject record...

2. Try to get a cert from any CA other than Lets Encrypt without answering any emails sent to the off domain MX.

...

Then... install Lets Encrypt... bam-o! Cert heaven!

It's self-gawd-damn-fing-signed.

Re: Why isn't HTTPS everywhere yet?

#46
Three obvious reasons...

Cost to the end user $10-200/year - even more on Heroku($20/month).

Configuration/Setup sucks - seriously you are supposed to run a bunch of unix commands, copy something to a server, and the whole process isn't user friendly.

Limited end user benefit - A business owner and user up until recently hasn't thought much or cared much about information security outside of online purchases.

Until it is cheap/free and once click easy, it won't be everywhere.

Re: Why isn't HTTPS everywhere yet?

#47

Earlier quoted context omitted.

The cross sign is too far up the chain. If you cross sign a self-signed cert what do you get? A Let's Encrypt Cert. Domain Ownership is not the same as file ownership.

Of course the cross signed cert works! That not the point. The cross signature is worthless if the signed cert beneath it is self-signed. If Identrust cross signed self signed certs, the self signed cert would be trusted too... and it would "work" in all browsers... Coly Tarry Frap Tarts! you're daft. Here try this: 1. Setup a domain with an MX record that points off domain and a dmarc p=reject record... 2. Try to ge…

I don't think you understand how the CA system or Let's Encrypt works.

IdenTrust signed Let's Encrypt's intermediate certificate[1] using their trusted root certificate. This intermediate certificate has the CA flag set, so other certificates signed by it are to be trusted too. Intermediate certificates are used by all CAs.

When you run the client on your server, the client submits a CSR to Let's Encrypt's CA server. Let's Encrypt will then verify domain ownership (via HTTP, TLS or DNS[2]). This is done in accordance with CA/B Baseline Requirements, and their practice doesn't differ from other CAs who also offer HTTP[3] or DNS verification. If ownership can be verified, Let's Encrypt will then sign your certificate using their trusted intermediate certificate and send it back to you. It is thus not self-signed, but signed by a trusted CA key.

[1]: https://crt.sh/?caid=7395

[2]: soon!

[3]: At least one other CA (WoSign) does this, there are probably others I'm not aware of.

Re: Why isn't HTTPS everywhere yet?

#48

Earlier quoted context omitted.

The cross sign is too far up the chain. If you cross sign a self-signed cert what do you get? A Let's Encrypt Cert. Domain Ownership is not the same as file ownership.

Of course the cross signed cert works! That not the point. The cross signature is worthless if the signed cert beneath it is self-signed. If Identrust cross signed self signed certs, the self signed cert would be trusted too... and it would "work" in all browsers... Coly Tarry Frap Tarts! you're daft. Here try this: 1. Setup a domain with an MX record that points off domain and a dmarc p=reject record... 2. Try to ge…

@pfg:

I know exactly how CAs work. I've built several.

Wosign does not issue a cert without an email verification.

You can look on their website. There's a nice big box to enter an email address to verify your domain and get the free cert.

Sorry -- "Let's Encrypt" with file verification is not DV.

It's just not DV. Simple really...

And it's gonna break the web. Like netlify up there a few post... using rackspace and "Let's Encrypt". ehh. The first few months will probably be fine and then everything is gonna tank.

Until the smart realize that ACME is fine -- as long as you remove the "or file verification" text.

Re: Why isn't HTTPS everywhere yet?

#49
post #47

Earlier quoted context omitted.

Of course the cross signed cert works! That not the point. The cross signature is worthless if the signed cert beneath it is self-signed. If Identrust cross signed self signed certs, the self signed cert would be trusted too... and it would "work" in all browsers... Coly Tarry Frap Tarts! you're daft. Here try this: 1. Setup a domain with an MX record that points off domain and a dmarc p=reject record... 2. Try to ge…

I don't think you understand how the CA system or Let's Encrypt works. IdenTrust signed Let's Encrypt's intermediate certificate[1] using their trusted root certificate. This intermediate certificate has the CA flag set, so other certificates signed by it are to be trusted too. Intermediate certificates are used by all CAs. When you run the client on your server, the client submits a CSR to Let's Encrypt's CA server.…

[deleted]

Re: Why isn't HTTPS everywhere yet?

#50

Earlier quoted context omitted.

Of course the cross signed cert works! That not the point. The cross signature is worthless if the signed cert beneath it is self-signed. If Identrust cross signed self signed certs, the self signed cert would be trusted too... and it would "work" in all browsers... Coly Tarry Frap Tarts! you're daft. Here try this: 1. Setup a domain with an MX record that points off domain and a dmarc p=reject record... 2. Try to ge…

@pfg: I know exactly how CAs work. I've built several. Wosign does not issue a cert without an email verification. You can look on their website. There's a nice big box to enter an email address to verify your domain and get the free cert. Sorry -- "Let's Encrypt" with file verification is not DV. It's just not DV. Simple really... And it's gonna break the web. Like netlify up there a few post... using rackspace and…

You seem to think that a certificate authority is obligated to verify ownership of a domain by email (for DV certs). You are mistaken, and that's not the case. The mechanisms supported by Let's Encrypt to authenticate domains are just as good as email verification.

If you've been involved in a CA, then you should be familiar with the CAB forum baseline requirements for Verification Practices. https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf

> For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that[] the Applicant[] has control over the FQDN by: [...]

> 4. Communicating with the Domain’s administrator using an email address [...] ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ [...] followed by the Domain Name[];

> 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

> 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.

The approach used by Let's Encrypt meets this standard (of which email is just one of several options), and the methods they use are just as secure as using email. They specifically offer approach 6. above, which they call Simple HTTP, as well as other approaches that comply with 7. as outlined in https://letsencrypt.github.io/acme-spec/#rfc.section.7 Involving email in the verification process makes certificate provisioning harder to automate and adds no additional security.

Post reply on HN