Let's Encrypt now holds 35% of the market
nettrack.info
nettrack.info
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.
If you're not giving them that, I'm not sure what they would do with just the CA server (which is indeed open source, by the way.) If you're giving them the keys ... well, do you really want to trust every single big hoster with the keys to the internet? They would still have to pass (very expensive) audits, apply for root inclusion, etc., so it wouldn't be as simple as running the Let's Encrypt server stack.
Amazon and Google run their own independent CAs already, with Amazon offering free issuance as part of some of their products (with non-extractable keys). I'd expect Google to offer something similar in the near future. I'm reasonably confident that these companies know how to run a CA, but I'm not sure I would trust many other hosters with something like that.
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...
You don't present yourself in a way conductive to convincing anyone of anything.
(or, you have a legacy application which is architected a certain way, which is similar in my scenario of having a "non-cloud ready" application.. it's not a good reason to architect things in future this way)
[0] https://docs.sandstorm.io/en/latest/administering/wildcard/#...
[1] https://docs.sandstorm.io/en/latest/administering/sandcats/#...
dijit's complaints seem to focus on the case where a wildcard is shared by many logically separate services, as a convenience vs. getting a separate cert for each. This is probably the most common use of wildcards in practice, and it is indeed bad.
None of dijit's complaints apply to the case where the entire wildcard is really served from a single logical service that needs to generate lots of short-lived hostnames for browser-side sandboxing purposes, which is what Sandstorm is doing. Sandstorm is possibly the only infrastructure in existence which is trying to do this at a scale that legitimately cannot be solved without wildcards.
I think dijit is trying to say that each logical service should have its own certificate that does not overlap with any other service. For this purpose, a Sandstorm server is logically only one service, and as long as no other services serve from the same domain, the properties dijit is worried aobut should be no different from a service with a non-wildcard cert.
In reality this almost[0] never happens, but, it's probably rare for a CA to give out certs without some strict checking because of these insurances, not in spite of them.
But yes, I agree that it's not a good argument since it's basically a marketing gimmick and consumers aren't aware of such "protections".
[0]: https://www.cnet.com/news/fraudulent-google-certificate-poin...
But if you bought something actually valuable, the insurance is useless _even if it paid out_ which it never has. This is because the huge headline dollar value is the _total_ sum insured and individual claims are strictly limited to a far smaller amount.
Let's try an analogy. Imagine if Coca-Cola took out $10M insurance against Coke causing brain damage. Then it turns out Coke has caused serious and irreversible brain damage to everyone in the world who drank it in the last 50 years. Oops. The insurer says OK, just individually post us proof your brain damage was caused by Coke and you'll get 5¢ each. It won't cover the cost of postage, but too bad, up to 200 million people can claim on this insurance, and at $10M total that's five cents each so that's the maximum claim.
That's how the SSL "Insurance" works. People who can prove they reasonably relied on the insured certificate AND can prove they were damaged financially as a result can claim up to a fixed tiny sum of money, which isn't worth doing.
The insurance firms selling it know this is worthless, it would be illegal to sell such pointless insurance products to consumers in most of Europe, but fortunately they sell it to the Certificate Authority which isn't a consumer, and the CA has no reason to care that it's useless, it sounds impressive.
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.
For my experience, this still holds in Japan, and I've heard in Korea.
As far as Korea goes, they've got a whole different bag of worms going on, at least for a couple more years. Look up "South Korea Internet Explorer" for some astounding stuff if you've not heard of this before.
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.
I worked for an ISP in 2000 and we had to both send and receive faxes on "company headed notepaper" as a means of authenticating a request. All you needed was a word doc with the company name in bold at the top of the page.
When we hit this particular bureaucratic speed bump (mostly dealing with domain name registrars), and having no "company headed notepaper" ourselves (we were 20 people) we just fabricated it. It always worked.
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.
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.
Use example.com. It's the domain that's required to be always available for this and other purposes.
Dvorak user?
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.
I guess in latter case SSL would help, but what’s more likely, though, operator selling out or app developer?
Yes and yes. ISPs are racing as we speak to develop the technology to data mine their users and inject their own ads. Hopefully we will get the web encrypted fast enough to make it less economically attractive.
They want to know which sites you visit, what you search for, which movies you watch and what you shop for, and package it and sell it to anyone who will pay.
Individual developers could do the same, and we should find ways to prevent that, but they have less negotiating and lobbying power and users have more choice in what apps to use.
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.
We've yet to see if users will either (A) follow the on-screen, flashing red prompts, or (B) be trained to click through the warning screens due to their sheer prevalence.
Even in case B, it's a non-negligible probability that browser vendors respond by disallowing click-through. Just another step towards (re-)making the web into a nice, safe walled garden.
Would you clarify what you mean here?
That sounds malicious -- whereas having it no longer work after the certificate expires sounds like security, and everyone likes security. With enough PR, you can string together something that sounds like a legitimate concern, like "with privacy being a major concern, encryption has progressed leaps and bounds past what we had two years ago -- so even if we were to renew the certificates, we simply do not think our customers' data would be safe when handled by these old devices."
Dystopia.
Or encryption will just get backported to http eventually. I never understood why they didn't just do that in the first place.
There was some talk about SNI encryption in the TLS working group. Not sure where that went, though.
I can't see how you could encrypt SNI without pushing TLS out to at least two round trips, which would suck for the Web although it might be tolerable in other applications.
One option that does occur to me would be to shove say, a 32-bit SHAKE(FQDN) instead of an FQDN in as the identifier. This way we don't show eavesdroppers the actual FQDN we wanted, although they can try to guess and discover if their guess was right at their leisure. So it doesn't prevent a sophisticated attacker verifying that we connected to vpn.example.com not www.example.com on the same IP address + port, but it does make it essentially impossible for them to find out that our server has a site named xy4298-beejee-hopskotch-914z.example.com by inspecting the traffic.
The server knows all the hosts it serves for, and can work out 32-bit SHAKE(name) for them and pick the right one or reject it without revealing anything extra. The birthday paradox means this is likely to have conflicts above a few tens of thousands of vhosts per server, but that's already getting into deeply bulk hosting territory where you don't care too much about security anyway. Ordinary people aren't doing much more than hundreds of distinct sites per IP address so conflicts for them would be extremely rare.
tshark -T fields -e ssl.handshake.extensions_server_name
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.
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.
Having thought about this a bit more, that would be an browser option that we could use today without any general convention. Turning on the "No script execution without https" option would break very little and would prevent more than just MITM attacks.
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.)
Context: https://security.googleblog.com/2017/09/broadening-hsts-to-s...
Thank you so much.
Thank you for all the work you do. It is a great service you have given the world at large.
1: https://www.infoworld.com/article/2623829/authentication/wea... 2: https://www.pcworld.com/article/249242/verisign_hacked_what_...
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.
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.
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.
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)
CACert says this is trustworthy because you have to know somebody who knows somebody who knows somebody etcetera. The profiles with a single photo of a swimsuit wearing young woman and a generic-sounding name that say they know me from school on Facebook every few weeks can tell you what happens to that idea at scale.
In contrast all the trusted public CAs (commercial or not) have a bunch of employees either directly making validation decisions according to some company policy or writing software to automatically make such decisions.
In theory maybe CACert's model really could work, but what it definitely can't do is work the same way as everybody else. So it was very hard to get anyone to give them a chance, still less after they started to have internal squabbles.
You are correct that gaining trust takes time, but what a conventional CA does (with the exception of maybe Verisign and Thawte which are _really_ old) is they first get an existing trusted CA else to sign a subCA certificate saying they trust the new CA. The ordinary "Let's Encrypt Authority X3" certificate is signed by IdenTrust (it says "DST Root CA X3" on it but the Digital Signature Trust no longer exists). There's another copy of the same certificate signed by ISRG, but that's only trusted in much newer software. Modern Firefox, current macOS or iOS, but not say, Internet Explorer 10
Well, CACert insisted on validating people but it turns out that it's not really necessary to know your customer to issue DV certs according to Baseline Requirements. Let's encrypt understood it and just did a minimal required job to be accepted (it's still a lot of work).
Instead of verifying people I'd gladly see X.509 replaced with OpenPGP w.r.t. trust model so that I could see who trusts who and why. OpenPGP has a mode of hierarchical trust with trust signatures, additionally they can be limited to a domain, that could be used to give people power to issue their own certificates for their own domains.
It's just a statement, with no emotion added to it from my side.
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.
If you need wildcard most likely your have some sort of production platform and probably make some profits, at least $5 a month for a cert.
Full disclaimer: have nothing to do with cheapsslshop but been their happy client for few years now.
The actual solution to this should be for any of those providers to provide the ACME certificate management protocol, and then if letsencrypt fails, I can point certbot at it.
Every year I'd preempt it and email our procurement and IT teams asking for a renewal months in advance (knowing the red tape means I'd get it JIT).
And, every year it wouldn't be renewed or bought until the day after expiry when I had enough complaints from people to light a fire under someone's arse.
The whole cert-package back and forth was a nightmare, am glad LE exists with auto renewals (or even manually pushing a renewal with one line is easier than the old).
I have a wonderful suggestion for anyone who wants to combat this problem: put the end date in your agenda! If you're a busy person put multiple notifications about it, or learn to look in advance in your agenda.
My comment was more a general statement to combat a type of procrastination (a deadline which must be met slightly before its date), specifically with the mechanic of both automated and manual subscriptions. Calendar reminders work wonderful with _both_.
I can also think of various scenarios where you don't want certificates to be renewed. Or well, maybe you don't but the users would. Like for example when your server no longer works, or got confiscated. A low timeout aids in lowering the amount of those certificates.
I have automated tickets created when I need to do things that I haven't automated yet, but, I still want to automate as much as possible.
I have not run into the problems that you're suggesting I should've. If a server no longer works or was confiscated, why would I still have DNS pointing at it? And does it really matter if I have some servers renewing certificates unnecessarily anyway?
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.
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.
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-...
It's kind of crazy, actually: it's more expensive for you to prove who you are than it is for the attacker to NOT prove who they are. Security should be about raising costs for the attacker, not lowering them!
And, as you know, neither Let's Encrypt or any other DV CA's check or verify any information except control of the domain itself.
That's why those certs are called Domain Validated instead of Org Validated ;)
The broader point is that whether that metadata is visible or not is what renders the OV to be the same literal value as a DV; even to a security-minded audience, an OV provides literally no extra value over a DV to the website's audience/customers, because it's effectively invisible. And EV does, on some browsers, but the positive benefits of EV are diminishing.
And because OV ~ DV to its users, the security value of OV over DV is nil; they are interchangeable for the purposes of protecting a website.
They might have more value, depending on the app, on other protocols, but for HTTPS, browsers have effectively rendered them identical.
If you submit a CSR with any of these fields, and you're requesting a DV certificate, the CA will discard those fields. Any sane CA implementation will cherry-pick only a whitelisted set of fields from the CSR, make sure the values have been validated according to the Baseline Requirements and root policies, assemble the certificate from that data and sign the result, ignoring all other fields (or discarding the request).
CAs that run something like sign(user_submitted_csr) would not last long in any of the major root programs.
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.
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.
Sounds like you're running the wrong web server for your needs, then. Every OSS web server has several methods for getting LE certificates implemented mostly by volunteers (my company implemented it in Virtualmin, both the OSS projects and commercial products, within a couple days of it being available, maybe even during the beta I don't recall exactly, and we're just a couple of developers), and you don't have to have an enterprise contract to make suggestions.
AWS has their own CA that issues free SSL certs for their customers for use with stuff like CloudFront, I don't see any reason Microsoft couldn't do the same if they're not willing to play nice with Let's Encrypt.
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.")
- Opaque and uncommon/needlessly-unfamiliar command-line management toolkit (seriously, what is so difficult about 'output text, receive text as input' in 2017?)
- I cannot, yet, fully manage a Microsoft host from the CLI. What I consider to be 'fully managed' revolves around: installing software, updating software, adding/removing/'managing' users, setting up basic server-like features such as simple firewall rules, viewing common log-files ('user X logged in', 'software Y tried to execute Z task, the result was A'), starting/stopping/troubleshooting daemons, etc
- Pick a major config-management system (my direct experience is with Puppet/Chef/Ansible/Salt). Configuring them to play nice with Windows-anything is an order of magnitude more difficult than even the most baroque *nix-like operating system.
- Licensing. Srsly, charging for the operating system, THEN the web server, AND the 'remote desktop server', PLUS the mail server... is downright punitive. Microsoft does exactly none of these 'well', but they still think they should be able to charge money for it. Their customers, in my opinion, must be masochists.
Lest I be accused of being completely unfamiliar/anti-Microsoft, here's a couple of things I feel they do quite well:
- remote/centralized user management (seriously, Active Directory's extensions and integration of LDAP/Kerberos are quite impressive). Pity it's not even remotely open-sourced, as such any modifications (hesitant to use the word 'improvements') are effectively prohibitively difficult to bring forward unless you're a Microsoft employee, directly assigned to the Active Directory group, in good standing with your direct manager and his manager's manager.
- AAA (authentication/authorization/accounting) - given their AD prowess above, they'd have to be a special kind of stupid to foul this one up. To their credit, it is amazingly easy to assign RBAC to a group of users and apply it site/directory/'forest'-wide, then go back and bean-count exactly which users did what and when, if needed. For a lot of environments, this is a huge plus.
Still, for the vast majority of 'webby' environments, in my professional opinion, Microsoft hasn't been able to hack it for at least a decade now. The market has moved on to more powerful, less costly, more manageable/scaleable platforms. If you're running an application, or even serving basic web content, on a Windows-anything, you're needlessly wasting your business time/money/agony if you choose to implement it on a Microsoft stack.
I recently switched all clients to Linux and plan to abandon this approach as I was after proper user/authorization management between my Windows 7 clients and a Linux based NAS. With Linux the integration via ssh/sshfs is much easier and fits better to the Linux authorization model.
As a comparison: Setting up AD properly on all parts did cost me at least several weekends. Setting up sshfs only few hours. And the latter is much more responsive...
^^^ PowerShell solves this. (AD,DNS,IIS,Exchange,DPM,Hyper-V...)
- I cannot, yet, fully manage a Microsoft host from the CLI. What I consider to be 'fully managed' revolves around: installing software, updating software, adding/removing/'managing' users, setting up basic server-like features such as simple firewall rules, viewing common log-files ('user X logged in', 'software Y tried to execute Z task, the result was A'), starting/stopping/troubleshooting daemons, etc
^^^ Solved by PowerShell (You can even install a GUI-less version of WS2016 and all these will work.)
- Pick a major config-management system (my direct experience is with Puppet/Chef/Ansible/Salt). Configuring them to play nice with Windows-anything is an order of magnitude more difficult than even the most baroque *nix-like operating system.
^^^ I use Ansible Tower to manage a mixed WS and Linux fleet with great success, I only need to run `kinit` once every day to obtain a ticket, all logins afterwards are passwordless.
...because they're all separate pieces of software?
* 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!
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.
This is done because it reduces the danger from collision attacks of the sort which worked on MD5 and are likely to be possible for SHA-1. The random serial number makes it impossible to guess what the signature on the certificate you're getting will be before it's issued to you, so you can't use a collision attack (other types of attack could work, but those have never turned out to be practical on a modern crypto hash even when it's "broken" like MD5).
They chose to make the serial numbers random because that's near the start of the certificate document and collision attacks are only defeated by randomness that happens as early as possible in the document.
1. https://resources.datica.com/compliant-cloud/articles/guides...
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.
Delivering browser exploits by injecting into unencrypted traffic is common practice.
Example (out of many): https://www.techdirt.com/articles/20140908/07191228453/comca...
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.
Injecting some Javascript into your static, non-sensitive pages is a great way to start an attack from inside your LAN.
They need wildcard certs and they'll go to 90% (some companies will still need to use more "reputable" companies).
99/yr for a cert was too much, though, and everything very cumberstome compared to Let's Enctrypt
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.
I haven't looked into this for about six months - I just bought a wildcard SSL certificate for 70$ and called it a day.
There are other ways too, but this is the easiest.
Are you using docker to spawn nginx ?
Docker services are not long running processes on a base OS. The entire OS is pretty much freshly created when you spawn a container. This gets to be an issue with letsencrypt.
What we do is take a 3 year certificate and bake it into docker build. So we only have to mess with it very infrequently. I can shutdown and scale my nginx containers (meaning - spawn new ones). Since the certificate is baked into the VM, it works seamlessly.
We always have a manually managed reverse proxy in front. For us, it takes care of TLS, caching, and makes me personally feel better than having the app HTTP/TLS stack facing the internet. This is just an nginx container with `/etc/nginx` mounted.
We also run certbot in a container. The two share a volume holding certs, and we do `certonly --webroot` to grab new certs. The container is not permanent, but launched from a script that essentially wraps certbot. Just need to disable the TLS vhost for a bit manually, and don’t forget to setup cron to refresh.
well that is both your prerogative as well as your expenditure. We work in regulated spaces (finance in India) and dont get to have a lot of leeway in hosting and infrastructure. Docker is a lifesaver that way. Which is why we like letsencrypt, but it is a blocker for those of us using docker to run nginx itself.
I usually copy a vhost config from one of our templates, comment out the TLS vhost, reload nginx, request cert, uncomment TLS vhost, reload nginx.
So, I'm not sure what's not possible in your setup? Unless there's a limitation on what kind of volumes you can connect to your containers?
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.
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
I haven't looked at Docker in a long time, but isn't there something called an entryscript? I'm not sure I'm remembering the name correctly -
- yep, entrypoint script not entryscript.
I remember something about setting up Wordpress in Docker and the official docker image has this type of script that initialised the database just once.
Might be worth looking into just for interest (maybe not for fixing this 'issue' as you point out its cheap to get a 3 year cert). I imagine one time init commands would be useful to have in their own right anyway.
[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.
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?
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.
The basics are First there needs to be some sort of government agency that can say authoritatively which companies exist in their country, and either give a date when they were created or a "serial number" in some sort of register - preferably via a secure online API. Second the country must have some reliable "business directory" or similar that lists authoritative contact details for that type of business. For example Dun & Bradstreet. This is to be used to phone the business up and ask to talk to someone about this certificate they supposedly want issued.
However you're quite right that places like Delaware or the United Kingdom, despite having a reputation as perfectly law-abiding places actually have very lax regulation for starting dodgy companies; the only reason scammers aren't buying EV certificates for dodgy company names in those places is that it doesn't matter. The day we make ordinary users demand an EV certificate to trust they're really dealing with "PayPal" is the same day scammers will start brass plate companies in London or Delaware named "Pay A Friend, Incorporated" or "My Pal, Ltd" or "PP Internet Payments" or whatever. Fools will still get separated from their money. No technical fix (and EV is a technical fix) can prevent that.
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...)
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?
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?
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.