Slashdot Mirror

Let's Encrypt has short-lived certificates, which are kinda useless and annoying when you have a device that is *not* a general-purpose computer capable of running their scripts.

What is the web server itself running on if not "a general-purpose computer"? If a special-purpose computer locked down to run only particular web server software, this particular web server software can include an ACME client. Certbot is not the only ACME client that can retrieve a certificate from Let's Encrypt or another ACME CA.

Am I really going to do a manual process on every cable modem, WAP, router, printer, switch, AP, IoT device, etc, every 3 months?

No. The manufacturer of "every cable modem, WAP, router, printer, switch, AP, IoT device, etc" will include an ACME client (or some other means of renewing a certificate) in the software package that runs the web server in said device.

The real problem is configuring which domain a device uses, as Let's Encrypt issues only 20 certificates per domain per week under a particular registrable domain based on Mozilla's Public Suffix List. And I'm told it takes months for a dynamic DNS host or other subdomain provider to get onto that list. But if you manufacture hardware devices or publish commercial software, as opposed to gratis software that a user can install on a generic computer, you can do what Plex did: become a reseller for some trusted CA to issue certificates for subdomains of your domain.

using https over tor is just stupid.

I can see two main reason why a site operator might try using HTTPS to connect to a web server over an otherwise secure channel, such as a hidden service on Tor or I2P.*

One reason is that not all parts of all browsers are aware that hidden services are secure channels. The W3C has published a spec titled Secure Contexts, which recommends that web browsers block use of sensitive JavaScript APIs by non-secure sites. Even script-free sites cause the browser to show a warning about an insecure context if a document contains a form, such as a login form or an editing form. Until user agents start treating hidden services (*.i2p and *.onion) as potentially trustworthy origins, sites using these APIs must use HTTPS to build a secure context.

Another reason relates to typosquatting. If a user mistypes a hidden service's hostname, such as facebookcorewwwi.onion, the user might end up connecting to a server controlled by an entity other than Facebook. To fight this, some certificate authorities have begun to offer Extended Validation certificates that apply to hidden services, assuring the user of the real-world identity of a hidden service's operator.

* The I2P community refers to hidden services as "eepsites".

Marking cleartext HTTP as "not secure" is actually the eventual plan, as I understand blog posts by Google, Mozilla, and DigiCert. First documents delivered over HTTP containing a password form was marked not secure. Then documents delivered over HTTP containing any forms. Then documents delivered over HTTP containing scripts. And finally, all documents delivered over HTTP other than from localhost.

Something doesn't add-up:

During the past year, Let's Encrypt has issued a total of 15,270 SSL certificates that contained the word "PayPal" in the domain name or the certificate identity.

(Emphasis mine).
But according to Let's Encrypt, their certificates don't say anything about identity:

Let’s Encrypt is going to be issuing Domain Validation (DV) certificates. On a technical level, a DV certificate asserts that a public key belongs to a domain – it says nothing else about a site’s content or who runs it. DV certificates do not include any information about a website’s reputation, real-world identity, or safety.

Can someone explain what the author meant by the term "certificate identity" in a Domain Validation certificate? It almost seems like the author of the article is conflating the concepts of DV certificates and EV certificates into one. Or am I wrong, and DV certs do indeed have an identity?

In researching this a bit, the CA security council as well as some certificate authorities are pushing browser manufacturers to treat DV certificates differently from EV certificates, where the site owner's identity is verified. This would make sense. There's some politics going on here at Mozilla: according to Wikipedia, Firefox used to treat DV certificates subtly differently from EV certificates, but they changed that once they launched Let's Encrypt.

In case you have not noticed, the cheapest of the EV Certs is $1000 a Year

Digicert has them for $224 for 1 year, or $165/year if you buy a 3 year cert. If you're serious about distributing a kernel mode driver, $165 shouldn't be too big of a hurdle to overcome even for a non-commercial organization.

No, the OP isn't saying that at all. Public key encryption is computationally expensive so SSL implementation use asymmetric encryption in order to securely establish a session key. After that, faster, symmetric encryption is used. Unless you've been living under a rock, it has been discovered recently that the algorithms used to generate those symmetric keys were not well implemented and, therefore, the keys could be guessed. (Those also rely on a prime number which was cut and pasted which is what the OP is referring to here). It doesn't matter how secure the key exchange is if the key itself can be guessed! https://www.digicert.com/ssl-c...

I think the LibreSSL people have shown that any such project should probably be restarted from scratch.

Overall, my experience with dealing with various libraries is that what someone really needs is to write a library that basically wraps connect() accept() write() read() and close() so that people can just do SSL without needing a billion steps that are poorly documented and trivial to completely fuck up.

While I'm begging, I'd also like someone to make a modern SSL cert tool that handles all the fancy shit from the 90's like Subject Alternative Names without having to use obtuse configuration files (what's that, you manage certs for several different domains and have to completely rewrite your configuration file for each of them just to get the SAN list right and if you forget your certificates are all fucked up?). Bonus points if you make the program noob-friendly by changing the prompts to match what people are trying to do ("Common Name (e.g. server FQDN or YOUR name)" - in what situation is my name EVER appropriate here?) so people don't have to look up a tutorial just to figure out basic operation.

SAN certs allowed you to use one cert for both internal and external services.
http://www.digicert.com/subjec...
one cert registered to the Public and verifiable FQDN, with Alternate names in the cert something.local.

Internal CA's are very hard to deploy with BYOD these days.
(Bring Your Own Device)

Now, from the people who brought you the Active-X security hole, we have a new Silverlight-based security hole.

1. Buy Authenticode code-signing certificate.
2. Create web site with hostile code running under Silverlight.
3. Spam to get website trafffic.
4. User visits site with IE, Silverlight content runs, hostile code gets installed.
5. PROFIT!

Microsoft's model of "trusted code" doesn't involve anybody actually testing or looking at the code.

Some background:
http://www.digicert.com/dv-ssl-certificate.htm
(No, I don't work for digicert)

The DV certs are those cheap http://www.nlnetlabs.nl/publications/dnssec_howto/#x1-290003.4 The administrator of the zone file can sign the zone.

"We do need a class of certificate that simply verifies that we're talking to the host we expect to be talking to "
See Bruce Schneier's Practical Cryptography for digital ID's.

"The browsers by default won't warn you if say your US bank's server cert is one day signed by CNNIC (China) while you're in China. Or vice versa." If you don't trust one of the Root CA's, delete it from your browser's certificate store. I do.

Prior to a few days ago, only Microsoft had such a certificate...

.
What do you mean only Microsoft had such a certificate?

Go to your browser and look at the list of trusted root certs.

ANY of them can sign a cert that says "Yeah I'm a valid cert for *.hotmail.com" and your browser by default wouldn't warn you.

And any of those CAs can sign someone else's cert (who can sign someone else's cert, repeat, rinse etc) and allow them to sign a "*.hotmail.com" cert and it'll work too.

CNNIC (one of China's CAs) has their cert signed by Entrust (whose certs are in most popular browsers out there): http://mozilla-xp.com/mozilla.dev.security.policy/CNNIC-cert-signed-by-Entrust

And just because some CA's cert is not in there doesn't mean it won't get auto-added by IE. In some scenarios CA certs can get auto-added by IE. For example, digicert's certificates do not appear in IE by default, but if you just go to https://www.digicert.com/ they'll show up in the cert store after that.

Just because you remove a CA from IE's (window's) list doesn't mean it will stay removed :).

p.s. I use Certificate Patrol on Firefox to help warn me of some CA/cert changes.

... and you would be incorrect. Name-based Virtual Hosting cannot be done with HTTPS.

...and then you would also be incorrect. One can use one IP with multiple host headers and multiple domains by using a UCC Certificate. And I know this because I am doing it right now for 5 domains with one IP and one UCC cert.
http://www.digicert.com/unified-communications-ssl-tls.htm

We typically just reuse our wildcard cert from DigiCert. They allow as many resigns as you want.

http://www.digicert.com/

Basically the registrars need to be pimp slapped a bit: certificate registration shouldn't cost anywhere near what it does, certificates should be purchasable for whole domains, etc.

Wildcard certificates do exist and aren't that expensive. We use them and they seem to work fine for most things (with 1 or two non-HTTP-server exceptions)

RTFA.

You don't get a "green" cert. You get an EV-SSL, or, Extended Verification SSL. It's not like MS invented something horrible to extort money out of people. FYI, Firefox and Opera implements anti-phishing toolbars as well.

http://www.digicert.com/ev-ssl-certification.htm

And, guess what? cost of the EV-SSL, along with payments to banks, credit card processors, etc... are just a part of the cost of doing business.

-=- Terence

Here's google's cache of the front page that we beautifully slashdotted. Also, on a related note, many companies offer free SSL certificates if you do a little business with them. Ever-popular GoDaddy recently joined the ranks of those companies. They started offering free SSL certs to open-source projects.