It's so strange that you have to ask someone's permission to use encryption[0]. Certificate authorities should've been (should be?) optional. SSH came out around the same time and its Trust-on-First-Use is a much better system.
Back in the early days you couldn't get a certificate without faxing in a copy of your business registration. A certificate authority's digital imprimatur implied something substantial about the credibility of a site, however imperfect the process. But as the certificate authority market diversified there was a race to the bottom in terms of credible certificate authorities. We've been at that bottom for so long that it does seem ridiculous that we didn't have Let's Encrypt earlier.
Well well, guess who could easily spoof that one.
> A certificate authority's digital imprimatur implied something substantial about the credibility of a site, however imperfect the process.
Not just the process. SSL downplay attacks and lack of certificate pinning already existed back in those days.
As long as those attacks are unknown you may still be reasonably secure against a MITM from a banana state government or a random ISP.
Also, lets not forget that running your entire website on HTTPS was expensive on resources before the 10s.
So the argument "because we can" makes sense. That doesn't mean all that information has to be encrypted. However, if you want to harm a surveillance state, then one act is causing significant noise. Uninteresting, encrypted data is noise and potentially yields plausible deniability.
The other argument is "because we have to". Different attacks have been demonstrated on that one: hostile networks such as ISPs injecting ads, hijacking DNS, open WiFi, impersonating fraudulent websites are just a few examples.
For my experience, this still holds in Japan, and I've heard in Korea.
I don't think the Web will become fully encrypted by virtue of everyone caring enough to move to HTTPS.
The knockout punch for unencrypted sites will come when browsers make the decision to not load plain HTTP sites by default in order to protect their users. At that point, for the vast majority of people, the Web will be 100% HTTPS because they'll never see a site that isn't HTTPS.
We just have to get the encryption percentage high enough to allow browsers to finish the job.
That would be a terrible idea: it would break every "http:" link in existence, requiring people to edit billions of documents. And if "modern" browsers started pretending that "http:" meant "https:", it would break every other browser and lots of bots.
Or encryption will just get backported to http eventually. I never understood why they didn't just do that in the first place.
1. TOFU won't scale - if I have a single SSH host, I can easily verify the server key out of band, and then never change it (though that's quite an insecure proposition if you ask me). How would you do this to _every single website you visit?_ And if you don't verify out-of-band (like calling up the host), how do you know that you're not being massively MITMed? And then when you leave your house and go to an airport and get a "your certificate changed", all it means is that _now_ you're connecting to the real page, and not MITM page. And even if you verified the original cert and now get a "site certificate has changed". It could mean that the owner rotated his private key. What do you do? 99% will just say "false alarm, ignore, move on".
2. WoT - It's a false sense of security. You're trusting that random people on the internet will 1. Bother doing _any_ verification before signing someone's key and 2. People will keep their private keys safe from botnets. And the network has perverse incentive - the less verification a group does, the more cross-signing they'll do, the more "trusted" it is.
SSH works on the premise that you should know, or have a way to check, the key for the server you are connecting to. That really doesn't happen with HTTPS.
I'm one of those people. The grocery list app I use doesn't use SSL and I don't really care because it's just my grocery list lol.
Sorry for the ignorance, it's a legitimate question.
In one somewhat recent example, a non-HTTPS page was modified in transit by an attacker to inject Javascript code which did a denial-of-service attack against github. Had the page used HTTPS, the attacker would not be able to inject that Javascript.
This was enough to convince me to add https to my static blog.
n-gate.com will make sure of that http://n-gate.com/software/
I remember, one of the arguments that the Comodo CEO had on the forum was a rant about LetsEncrypt attacking their business model. While there were a lot of weird things in that rant, it does seem reasonable that a free service will erode the paid, commercial offering. So I would be curious if Letsencrypt is enabling people who otherwise would not have gotten an SSL cert, as well as the extent Letsencrypt is taking away customers.
I would also be curious to see what happens when wildcard SSL certs are launched.
> And because 85 percent of those sites never had HTTPS before, it's already significantly boosted the total fraction of sites that are encrypted on the web as a whole. Based on numbers Mozilla gathers from Firefox users, encrypted sites now account for more than 42 percent of page visits, compared with 38.5 percent just before Let's Encrypt launched. And Aas says that number is still growing at close to one percent a month.
(I work on Let's Encrypt.)
Thank you so much.
Thank you for all the work you do. It is a great service you have given the world at large.
Context: https://security.googleblog.com/2017/09/broadening-hsts-to-s...
DV certs though ... largely felt like a scam to me, back when I learned how they work in the early days of the web.
Since Lets Encrypt, every last thing I put on the Internet leverages SSL. Prior to Lets Encrypt, I had purchased a single SSL cert, ever, because I don't have the money to throw at every little thing I like to create and play with.
Admittedly the plural of "anecdote" is not "data", but assuming I'm not special, my suspicion is "very much yes".
For my personal stuff, it is both. I paid for a single cert on my little server, but it hosted a handful of domains. It wasn't practical to secure the rest with only a single IP or to expensive to pile them all on a single cert. Let's Encrypt replaced one paid cert and secured 5 other domains that I otherwise wouldn't have.
This bled into work where we replaced all paid certs(except wildcards, coming soon) and secured hundreds of domains were not before.
With Wildcard certificates coming to Let's Encrypt, I think they will only increase in users. (https://letsencrypt.org/2017/07/06/wildcard-certificates-com...)
Do cloud hoster offer a copy of the service from their datacenter? Otherwise it could be a single point of failure / single attack vector, right?
Why? Not a single point of issue. Given now that it has now 25% market share, it's a high profile target, and given he short cert lifetime aggressive updating is necessary meaning you could receive a underhanded cert in case someone gets access to the high profile target. If Let's Encrypt is not a startup and doesn't plan to make money, then there should be no problem to release the whole service as DEB/package so that every big hosted can run a clone under a different name. Or is LetsEncrypt in the business of gathering analytics and selling the usage data? I think no.
I wrote a very opinionated and ranty blog post which goes into more detail ( but strongly implies people lazy :( )
https://blog.dijit.sh/please-stop-advocating-wildcard-certif...
[0] https://docs.sandstorm.io/en/latest/administering/wildcard/#...
[1] https://docs.sandstorm.io/en/latest/administering/sandcats/#...
You don't present yourself in a way conductive to convincing anyone of anything.
We'd love to work more closely with Microsoft. We've been talking with Microsoft and various Microsoft community members about building great support for IIS since before Let's Encrypt launched.
(And I'll say I'm only posting this because I've had some not-good experiences with certbot. It is essentially a big foreign environment nailed onto your host and another 'thing' to tend to. Or perhaps you would describe it as Ubuntu Linux being "network belligerent.")
Devil’s advocate: AWS rolled their own CA and cert management system.
It super simple to buy and add a paid SSL certificate to your Azure Web Site, but a paid solutions is not the topic of this thread.
* google "samsung multiroom app for mac"
* the second link leads to http://www.samsung.com/uk/support/tv-audio-video/where-can-i...
* click the link that leads to the main page
* no https!
which was quite confusing..I mean if google does not redirect to https, I was full within the range of sane assumptions about Samsung not supporting https but I see that they actually do, thanks!
I haven't looked into this for about six months - I just bought a wildcard SSL certificate for 70$ and called it a day.
So when it goes to start up it will fail because ther is no certificate in place? (If not then tell me why Nginx won't start).
If that's the case, don't link to where the certificate should be. That'll let nginx start, then the certbot-nginx tool can run and it'll add links to the generated certificates directly to your config files as part of the initilisation.
All it does is insert the paths to the certificate files before the final closing bracket of any server block that listens on port 443.
I use Ansible and automate the install of new server/sites, unless there's something extra different with Docker, the automation process should still work fine. It also still works if your config is setup to redirect all incoming from port 80 to 443.
Docker VM are like short lived machines with no dependency management in init. But 70$ for 3 years is a cheap price to pay versus giving up docker , nginx (vs traefik), etc
It wasn't worth it in the end, perhaps you could look into traefik or caddy. Both can automatically request and refresh certificates for you, caddy is good for hobby projects and is very easy to configure, traefik offers a lot of features and can be a bit harder to setup, but is truly awesome if you connect it to an orchestrator for automatic request routing.
Are you using docker to spawn nginx ?
[1] https://letsencrypt.org/2017/07/06/wildcard-certificates-com...
Many people who don't live in the tech news bubble like we do might not have even heard of let's encrypt, or haven't realized that they could use it. Or the bad old "never touch a running system" mantra at work.
https://w3techs.com/technologies/history_overview/ssl_certif...
Every CA is growing except StartCom who were distrusted by most players last year (and Microsoft, belatedly, remembered this year) and have recently declared they're throwing in the towel, won't try to get back their trust.
The big categories which shrank are "None" and "Invalid Domain", ie people who didn't have SSL, or were on shared hosting and never switched it on for their site or whatever.
How about cPanel and others who bundle Comodo certificates?
No, I think Comodo are doing very nicely off this. They've correctly judged that they're never going to be the Maserati in this industry they need to be Ford or Toyota and too bad if some people sneer.
You also have more privacy. An attack can see that you are accessing Hacker News but not necessary what comment section you are on (though it can sometimes be inferred by the page size).
You might not care about that about your oldschool static side but someone who lives in suppressive countries might because it might make a big difference if they only access Hacker News for the latest and trendiest node framework or if you actively research the comments about articles how your country does something bad.
Example (out of many): https://www.techdirt.com/articles/20140908/07191228453/comca...
Delivering browser exploits by injecting into unencrypted traffic is common practice.
Injecting some Javascript into your static, non-sensitive pages is a great way to start an attack from inside your LAN.
And now I couldn’t be happier I switched to Let’s Encrypt. Automatic renewals mean no more working through the partially-manual, email-based process we had to use with Comodo. And free+automated means I don’t think twice about using https on every new subdomain. Really, I don’t think at all about https anymore; it just works.
For the dev and staging environments, I used a sub-domain prefix: app1.staging.example.com, downloads.staging.examplecdn.com, etc. There's a script that looks through the deployed systems in it's environment and configures the proxy server appropriately -- including running certbot if needed to get certificates.
I used let's encrypt initially so we could actually test real SSL without the hassle of new certificates, especially when we wanted to deploy a new environment. It worked so well we just left it in when we deployed to production.
The cost of certificates is nothing compared to the effort to get someone to put it on the company card, renew it (and answer questions about what it is a year from now, yes we still need it), manage the private key, etc. Let's Encrypt is better in every way.
Not only these certs are for 3 months, but what if their renewal services have hiccups. Not wishing them anything bad, but I can imagine that for whatever reason (including root cert being invoked if they happen to encrypt sites that normally wouldn't do like c.p.) I imagine that 35% of net rushing to a local cert provider to get a paid solution or face no traffic to their site at all.
Besides, the times of Thawte's 1999 when single cert was $150 are long gone; you can get a decent Comodo for $4.99 per year these days.
In other words, I remember faxing data into verisign or thawte back in the day (not even that long ago), but OV is just not worth paying for anymore: OV provides zero value, now that DV certs are accessible. Someone who had access to your domain could just get a DV (or LE) cert and no one would be the wiser.
I'm not sad to say that Comodo wrote their own death certificate (ha) by racing to the bottom. It's hard to beat free and open source.. the only thing they've got to hold onto now is EV, and that's of diminishing value now as well.
The Baseline Requirements require certificate authorities to be able to verify the correctness of the information that they include in each certificate -- including for DV. See the first subsections of section 3.2.2 of
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-...
I don't know if every DV CA does this, but I got a couple of StartSSL's free certs a while back (before LE was around, and before the WoSign acquisition and subsequent debacle), and I recall the documentation saying "because this is a DV cert, we're just going to ignore all the metadata in your CSR and generate a certificate with those fields blank", or something along those lines.
Value in terms of cost, or in terms of utility? And if the latter, care to explain why? I know almost nothing on the business/political side of certificates.
Namecheap (my host, until I get around to switching) still is, for business purposes. (their customer service rep gave me some BS about "security" as to why, but it's really because they make a ton of money selling certs)
It's already gone bad for the security field ;)
Running a ACME authority is not hard. The CA's just don't want to cannibalize their business.
They basically position it as "As well as integrating with Windows we also make everything work automatically with your weird Unix stuff like Apache or nginx" but it's an ACME service under the hood.
ACMEv2 (the Internet Standard RFC when that finally gets published) is a bit nicer for a commercial CA because it spells out how you use ACME to say e.g. "Hey, I'm paying customer #383829, here is proof - give me certificates on my account". The only easy way this could have worked in ACMEv1 wasn't terribly compatible with the limited understanding of cryptography that say Steve in accounting has.
What is Extended Verification
Why would I want Extended Verification
Why would I look more legitimate to someone looking for Extended Verification? Because my business/personal information would be associated with the certificate or something?
Basically the only difference is that it gets you a green badge in the URL bar with the name of your business: https://i.stack.imgur.com/xmMnB.png
In practice, very few sites actually need EV. Domain validation is usually enough. (Troy Hunt wrote a pretty good article on this a while back: https://www.troyhunt.com/on-the-perceived-value-ev-certs-cas...)
Exactly. EV certs are tied to a business, and said business' identity is verified in the process. Where for a domain validated (DV) cert the CA only verifies that you control the domain/the server it is pointing to, an EV cert also has the business name (and browsers generally show that). If you own ringaround.com, I can register ringaround.io and get a cert for that and try to impersonate your website to users, but I'll have a harder time getting an EV cert for ringaround Ltd.
The limitation of course it that this requires users to actually check/notice the cert isn't an EV one, which is why the usefulness of EV is questioned.
But not to pick on the U.S.. if you're from outside the country, the U.S. is actually a pretty nice place to base your company. But, if you were the EV company, how would you verify a company in Nevis or Timbuktu? How will you REALLY know if that company is even legit or if the company just hands out "Corp" or "Ltd" or "IBC" to anyone who pays $50 on a credit card?
EV isn't quite a joke, but it's not really as useful as the companies pushing it make it out to be.
Sure, your communications are encrypted by what people perceive as an infallible algorithm, and all serious websites with forms force you to use it, but at what cost?
You: "Let's pick a session key, let's use method A, with the magic numbers 15 and 29. I chose my random number, and with A, 15 and 29 the answer was 4."
www.google.com: "Cool yes, method A with numbers 15 and 29 is fine by me. I picked a random number and my answer was 3."
Now both you and Google can determine that the secret session key is 9, because each of you knows _your_ secret random number and the number the other person got by using _their_ secret random number with the special method. But even if the other person lied and always picks the same number, the _result_ is random, because you did you part of the trick properly.
Nobody else knows it's 9, even if they eavesdropped on this conversation taking place, because they need one of the secret random numbers to work it out OR they need to solve a mind-bogglingly hard mathematical problem to get the answer without knowing the secret.
If the RNG isn't random then the protocol just broke and HTTPS turns into paperweight.
You usually get tracked by your browser and remote IP much easier than tracking details in the TLS connection.
However, if the https protocol itself is bugged at the TLS level, what can you do? What if the last few bytes of the ssl session number are always generated according to your unique hardware specs? What then?
I'm aware that this looks a lot like FUD, but it is rather a question, because I'm not peddling an alternative. Why implicitly trust any protocol?
The weird (and pleasant) thing here is that the $0 price is backed not by a shady business, but by a non-profit [1] that hires a stellar team of TLS/DNS/Internet experts that does most of its job openly and in a replicable way.
[1] Internet Security Research Group (ISRG)
They need wildcard certs and they'll go to 90% (some companies will still need to use more "reputable" companies).
I would like to see native ECC support and a more stringent validation mode that allows more than 3 months of certificate lifetime.
Let's Encrypt will sign your ECC keys now, but we'll sign with our RSA keys. We'll likely have our own ECC trust chain some time next year.
Although S/MIME isn't a real Wild West like some types of X.509 certificates, it has seen much less oversight than SSL/TLS ("Web PKI") certificates. There's also not really a great appetite for cleaning it up. If you want to be the hero in this story there's definitely an opening for that.
Of course there's a part of migrating certificates to Let's encrypt, but I find it more important that the HTTPS surface had grown that much.
1. https://resources.datica.com/compliant-cloud/articles/guides...
