Launching 2015: a New Certificate Authority To Encrypt the Entire Web 212
Peter Eckersley writes: Today EFF, Mozilla, Cisco, and Akamai announced a forthcoming project called Let's Encrypt. Let's Encrypt will be a certificate authority that issues free certificates to any website, using automated protocols (demo video here). Launching in summer 2015, we believe this will be the missing piece that deprecates the woefully insecure HTTP protocol in favor of HTTPS.
quick question (Score:5, Insightful)
how can one verify that this future "certificate authority that issues free certificates to any website" hasn't issued a cert to the NSA for your domain? is it possible?
Re: (Score:2)
Presumably there will be a collision detection mechanism that nixes the old certificate and alerts you to such changes by e-mail.
Yes, there are ways around it, but that's true of any CA.
Re: (Score:2, Insightful)
The fundamental problem is the whole concept of a "Web of Trust." How or why should I trust that a collision detection mechanism is in place, functioning properly, and has not been manually overridden? We've come full-circle to "I just have to blindly trust."
Comment removed (Score:5, Informative)
Re:quick question (Score:5, Informative)
Actually the US Department of Defense and dozens of other governments have their own CAs with which they could issue a certificate for your domain, if they wished to. Here's a map [eff.org] we made of them using our SSL Observatory [eff.org] datasets.
Nonetheless we should be able to use publication mechanisms such as Certificate Transparency [certificat...arency.org] to ensure that any compromise or compulsion of the Let's Encrypt CA could be quickly detected.
Re:quick question (Score:5, Informative)
Have you seem the list of CA root certs in a normal browser install these days? Its in the dozens, if not hundreds. A signed cert by any one of those is equally good for any site, unless you are also checking known signatures...
Re: (Score:2)
"A signed cert by any one of those is equally good for any site, unless you are also checking known signatures..."
What you are describing is what I already described via method #2. If and only if they are able to add their root public key to the user's computer will their fraudulently issued certificates successfully validate. Once it's added, then yes they can issue a fraudulent cert for any domain, and that user's browser will validate it.
"Have you seem the list of CA root certs in a normal browser inst
Re: (Score:3)
#1 does not require compromising the CA... Any CA is beholden to the government of the country in which it operates, and would be required to hand over the private key if ordered to do so. And the more people who have the private key, the greater chances of it leaking.
Re:quick question (Score:5, Insightful)
How can one verify that a different CA doesn't issue a certificate for your domain name to the NSA? It's happened before (including sub CAs getting compromised so new certificates could be created at will).
In order for traditional PKI to work, there needs to be a point of trust -- the certificate authorities. That also means trusting anyone that controls the certificate authorities (who may have the power of secret laws, subpoenas, and gag orders). If you don't trust the authorities, then you cannot trust PKI.
There can be public/private encryption without a centralized authority (SSH keys, PGP, etc). However, then it's up to each person to individually verify the authenticity of every other key. The certificate authority performs that role, so long as you're willing to trust them.
Re: (Score:3)
Public Key pinning [mozilla.org] is a small first step in the right direction, I think the problem is the first connection with the site, hopefuly something with DNSSEC could be added to help more
Re: (Score:2)
Re:quick question (Score:5, Informative)
It's called DANE, or DNS-based Authentication of Named Entities [wikipedia.org] and described in RFC 6698 [ietf.org]. The DNS record is TLSA, it associates a TLS certificate to a domain name.
Unfortunately a major browser vendor has yet to implement it. How about supporting the feature requests to implement it? https://bugzilla.mozilla.org/s... [mozilla.org]
Re: (Score:2)
Re: (Score:2)
And how is that worse than using HTTP?
Re:quick question (Score:4, Informative)
HTTPS requires active MITM attacks to eavesdrop. If one looks at the trail afterwards, there isn't any real way to glean the session key the two machines created... to get that key, Charlie has to actively step between Alice and Bob and capture their pieces, while pretending to be the other person. If both use some signature mechanism, Charlie is SOL.
What might have been better is early on, have Web browsers accept self-signed SSL certs, and show some grey icon for that. Certs validated and signed by a CA, a blue icon. EV certs, green. Couple that with a mechanism that detects an unexpected certificate change, and this could provide a decent level of protection, while making it obvious to the user that if they are concerned about security, do transactions with the green or blue color present.
Re:quick question (Score:5, Insightful)
...
What might have been better is early on, have Web browsers accept self-signed SSL certs, and show some grey icon for that....
Web Browsers DID used to accept self-signed certificates (and certificates signed without a known CA - or cert-chain.) People just clicked through and accepted them willy-nilly. That was a poor security model. Although the existing security model of having a swamp of independent Root Certificate Authorities (per browser) is not too great either, but at some point you have to establish whom to trust - and for most of us, it's the browser vendor. (Some of us prune the Certificate Authority list and distribute the new list with software imaging technologies....)
Re: (Score:3)
Currently, a browser will happily accept an unencrypted connection or an encrypted one with a certificate tracing back to (in this Firefox browser) a certificate from of of 92 authorities (some of which have multiple certificates), some of which aren't in English and most of which I've never heard of. With that many authorities, it seems like a reasonable bet that at least one is compromised and doesn't know it. The browser will have conniptions and claim loudly that the sky is falling if it encounters a
Comment removed (Score:5, Insightful)
Re: (Score:2)
EFF and Mozilla are included. I think that's a stretch.
Re: (Score:2)
The "certificate authority that issues free certificates to any website" can actually be one or many of the CAs that is popular today. This is just a new protocol for the way to get a certificate signed by one of these CAs. So if some CA issues as a cert to the NSA for your domain right now there is nothing here that prevents that CA for doing it when using this new protocol.
Re:quick question (Score:5, Informative)
There are two issues, encryption and trust. When you connect to Google.com, how do you know that you've really connected to Google.com? Right now, because Verisign (or somebody) has vouched that the certificate comes from Google.com (ip address by itself isn't enough). Without that vouching, there are all kinds of MITM/redirection attacks that can happen.
From a theoretical standpoint, encryption without trust is no more secure than plaintext transmission. However, from a practical standpoint, encryption blocks out a lot of script kiddies who sit on a wireless network with wireshark (incidentally, there is no way to verify that a WiFi SSID corresponds to a given base station, so if you're on WiFi you are almost always vulnerable to MITM attacks). The EFF, Mozilla, Cisco, and Akami are trying to raise the bar on the difficulty of the practical attacks.
So we're moderately reducing the ease of the theoretical attack, but the big problem is still there, "is this website trusted, or just encrypted?" Traditionally no browser has had a way to distinguish, but it looks like Mozilla is going to, so that's a good thing.
We still have the problem of trust though. It's probably the toughest problem in all of the fields of security and encryption.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
My apologies. The wiki article linked provides a decent primer (it also lists relevant specifications).
DNS-based Authentication of Named Entities [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
From a theoretical standpoint, encryption without trust is no more secure than plaintext transmission.
From a theoretical standpoint you've used trust and security in the same sentence, whereas they are are two completely independent concepts.
Secure communications means people don't randomly eaves drop.
Trusted communications means the people who read them are the people who are supposed to read them.
Without an encrypted channel you have zero security. Every idiot snooping on the wire can read what you wrote.
With an encrypted channel but no trust, you have some security. You need to directly involve a middle
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
how can one verify that this future "certificate authority that issues free certificates to any website" hasn't issued a cert to the NSA for your domain? is it possible?
How can one verify that any "certificate authority" hasn't issued a cert to the NSA?
But if your domain is currently running HTTP because you don't want to pay for an HTTPS certificate, giving the NSA a backdoor to decrypt your website doesn't seem like much of a drawback. Not that matter for most people, if the NSA wants to see your data, if they can't get it from you, they'll get it from your ISP.
CAcert (Score:5, Informative)
Comment removed (Score:5, Insightful)
Re: (Score:3, Insightful)
Depending on 'big names' can reduce the trust factor to near zero, and rightfully so. How do 'big names' benefit from our privacy? Where is the incentive to secure it? This is a monolithic industry. Supply and demand are silly illusions. 'Big names' are subject to big laws from big people and the whims of big money, obviously, that's what made their names so big. And now we expect them to bite the hand? I don't think so...
Re:CAcert (Score:4, Insightful)
Akamai wants you consuming lots and lots of video. Cisco wants you chewing up bandwidth like crazy. They benefit. But yes if push comes to shove between you and Homeland Security, you lose.
Re: (Score:2)
It isn't the encryption they would care about its you being comfortable consuming video privately. In particular people want privacy about their porn choices.
Re:CAcert (Score:5, Informative)
A lack of sufficient auditing capability is what has kept CACert out of most browser CA bundles.
StartSSL.com provides free entry-level certificates with some level of verification, enough at least to satisfy the major browsers.
Re:CAcert (Score:5, Insightful)
A lack of sufficient auditing capability is what has kept CACert out of most browser CA bundles.
Which is laughable considering some of the other CAs that are included.
Fantastic. (Score:5, Insightful)
This is a fantastic effort that will help people such as myself. I run sites across a dozen or so hosts, but they don't generate income and I really don't want to drop all that money into certificates. If I can get free certificates from a good CA then I'll gladly bump all my sites over to HTTPS.
Thank you!
Re: (Score:2)
Replace Cisco, and Akamai and then maybe.. (Score:5, Interesting)
Replace Cisco, and Akamai and then maybe I'll be convinced it's better than the current situation. But it's still oxymoronic service: A central authority that *REQUIRES* trust for people who don't trust anybody.
And what do you do for countries with draconian Cert laws like England? (They want a copy of your root cert)
The resulting entity would have to be incorporated in Iceland or something. FAR away from 5-eye's dragnets.
Re: (Score:3)
Cisco's involvement makes sense. They're pushing hard into "Internet of Things". They won't want the bad publicity or financial risk of delivering unsecured configuration UIs. Sure, they could install self-signed certificates but browser warnings about self-signed certs will generate support calls. If they can get the root cert into the other browsers (and as one poster above noted, it seems likely with this line-up), free certificates for the asking solves the problem.
Akamai, not sure what they get out of
Re:Replace Cisco, and Akamai and then maybe.. (Score:5, Insightful)
Replace Cisco, and Akamai and then maybe I'll be convinced it's better than the current situation. But it's still oxymoronic service: A central authority that *REQUIRES* trust for people who don't trust anybody.
First, if you don't trust Cisco and Akamai to that extent, how do you intend to avoid transporting any of your data on networks that use any of their hardware or software?
Second, I think a lot of people really have no idea how SSL/TLS actually work. There's two forms of trust involved with SSL certificate authorities. The first involves the server operators. Server ops have to trust that CAs behave reasonably when it comes to protecting the process of acquiring certs in a domain name. But that trust has nothing to do with actually using the service. Whether you use a CA or not, you have to trust that *all* trusted CAs behave accordingly. If Let's Encrypt, or Godaddy, or Network Solutions, is compromised or acts maliciously they can generate domain certs that masquerade as you whether you use them or not. As a web server operator if you don't trust Let's Encrypt, not using their service does nothing to improve the situation, because they can issue certs on your behalf whether you use them or not - so can Mozilla, so can Microsoft, so can Godaddy.
The real trust is actually on the end user side: they, or rather their browsers, trust CAs based on which signing certs they have in their repositories. Its really end users that have to decide if they trust a server and server identity or not, and the SSL cert system is designed to assist them, not server operators, to make a reasonable decision. If you, as an end user decide not to trust Let's Encrypt, you can revoke their cert from your browser. Then your browser will no longer trust Let's Encrypt certs and generate browser warnings when communicating with any site using them, and you as the end user can then decide what to do next, including deciding not to connect to them.
Seeing as how the point of the service is to improve the adoption of TLS for sites that don't currently use it, refusing to trust a Let's Encrypt protected website that was going pure cleartext last week seems totally nonsensical to me, unless you also don't trust HTTP sites as well and refuse to connect to anything that doesn't support HTTPS.
Lastly, if you literally don't trust anybody, I don't know how you could even use the internet in any form in the first place. You have to place a certain level of trust in the equipment manufacturers, the software writers, the transport networks. If all of them acted maliciously, you can't trust anything you send or do.
I don't necessarily trust the Let's Encrypt people enough to believe they will operate the system perfectly, and I don't believe they are absolutely immune from compromise. But I do think the motives of people adding encryption to things currently not encrypted at all is likely to be reasonable, because no malicious actor would be trying to make it easier to encrypt sites that have lagged and would otherwise continue to lag behind adopting any protection at all. Even if they are capable of compromising the system, that is quixotic at best. Even in the best case scenario they would be making things a lot harder for themselves, and in the long run getting people accustomed to using encryption with a system like this can only accelerate the adoption of even stronger encryption down the road.
What about the browsers? (Score:2, Insightful)
Have Apple, Microsoft, Google and Opera all pledged to add certificates for Let's Encrypt - and not just for future browser releases? Otherwise, we lose all of our IE12, Safari, Mobile Safari, Android, Chrome, and Opera users with these certificates.
strawman? (Score:4, Insightful)
Why should we believe that HTTPS (or i suppose more accurately TLS / SSL) hasn't already been compromised (i.e. by the NSA)?
Re: (Score:2)
Why should we believe that HTTPS (or i suppose more accurately TLS / SSL) hasn't already been compromised (i.e. by the NSA)?
So, the straw man you're referring to is the idea that if the NSA can break it, then it's useless?
Re: (Score:3)
Not useless, but also not what it says on the tin.
Re: (Score:2)
Why should I care? The NSA is tracking my move. That's a given. However in terms of my own personal life should I be more afraid of the NSA reading my credit card number and emptying my account (they have this info already), or should I be afraid of some 15 year old script kiddy doing it?
Security has a lot of granularity between everyone can read anything I say, and uber security not even the NSA can hack.
Identity? (Score:2)
I thought part of the reason for the cost of certs was the identity portion of the server. It's not just encryption, it's making sure that Citibank is Citibank not Bob DeHacker. I didn't see much talking about this, just about encryption.
At some point, somebody needs to pay for identity verification. Maybe a group of companies does it for free for a Better Net, but there will be a cost someplace.
Re: (Score:3)
The amount of identity verification required is very small. StartSSL is fully compliant and included in browsers by default, but it's very simple and takes only a few minutes online.
Bob DeHacker isn't going to be able to get an accepted cert for a MITM attack for a major company. Really, these days, the only thing that lights up the address bar green is EV-SSL. Your standard HTTPS site just puts in a tiny padlock in the address bar. And nobody's going to buy a certificate for a MITM attack on a site tha
Sure but... (Score:2)
What I'd rather have is sites not requiring a fuck-ton of Javascript, usually from other sites, to display anything or to work / navigate in even the simplest fashion. Content sites that use Javascript to display article text is particularly annoying.
Just my $.02.
Re: (Score:2)
Exactly. I work in an environment with very limited bandwidth (1.8Mbps private satellite link servicing ~80 people). SSL by default is the bane of my existence. Right now, I've got Cisco WAAS deployed, and it adds about another 30% of effective capacity to my link, and often more. If everything goes encrypted by default, then I lose all of that. I get no caching gain, no compression gain, nothing, unless I MITM the link, which is evil and causes no end of support headaches.
Encrypt what needs to be encr
Won't existing CAs complain? (Score:2)
Sure, they do business selling code-signing certs, wildcard and SAN certs but I have to believe that a not insignificant part of their business is selling boring, single-name certs for web servers.
If you can suddenly get SSL certs for your web server for free and have them work like a paid certificate (wide-spread browser and device support) won't a lot of people do just this?
Or will it be some kind of "we need support" thing where people keep buying them because of corporate policy and the "only" users wil
Re: (Score:2)
Some people will stick with the established CAs for better compatibility with older browsers or for the green extended validation bar. It's also not clear whether this service will support stuff like wildcard certs (heck it's not even clear right now how they are planning to validate certificate requests).
but yeah if this takes off it's going to be a tough time to be a CA.
Re: (Score:2)
NM read in more detail, it seems they will be validating based on the ability to put a file on an unsecured webserver (which will make life a whole lot easier for a man in the middle close to the server).
Re: (Score:2)
Yes they will. Just like cable companies, they will get the best laws that money can buy.
I predict in 10 years: money is privacy
No money == no Certs == No privacy
After all, money is speech (Thanks, you corrupt USSC!)
No money == STFU
Re: (Score:2)
Yes they will. Just like cable companies, they will get the best laws that money can buy.
When I posted my original comment I didn't think of this, but it's not hard to CAs to start claiming they provide a beneficial security service by validating certificate buyers, helping to keep bad guys from running encrypted web sites to sell drugs, defile white women and support terrorism.
Maybe they will agree to some kind of "national security compromise" that enables regulation of CAs and their continued monopoly status, of course in exchange for giving the NSA backdoor access.
Re: (Score:2)
When your in the business of selling random numbers, don't be surprised when someone undercuts you.
Fix the problem properly (Score:2)
The existing model is broken by the fact that CAs are not always trustworthy, the certs they issue to most sites are worthless as tokens of t
So many comments worried about NSA... (Score:2)
So I'm just going to send everythign in plain text instead. That'll show em.
If you need true secure communications, in as much as any such might be possible, there are other solutions for that, which don't involve any kind of central authority. (As soon as you have a central authority, you have the weakest link of attack for a larger target.)
This is encryption for everyone else, so passwords aren't being sent in the clear willy nilly by everyone who connects to their favorite sites from public wifi spots,
Re: (Score:2)
Replying to my own comment, reading some of the other comments that were posted since mine, I see have some reading up to do on this new fandangled SNI thing.. That's one problem barrier down :)
Obviously the NSA should do this (Score:2)
They are the encryption experts after all, who better to trust for your SSL certificate needs?
So how much power will this use? (Score:2)
Any estimates on how much power will be needed to run the crypto so a bunch of static web sites can put an S in the URL?
Re: (Score:2)
Re: (Score:2)
Actually, there's a pretty damn good reason why Slashdot *should* be private:
You (and I) are logged into this site. That means a unique identifier tied to our Slashdot accounts is sent to the server (in a cookie) with every request we make. This lets Slashdot know who we are, primarily for when we post a comment. The problem is, this unique identifier is sent in plain text; anybody on the same network as you or anywhere in the network between you and Slashdot's servers can see it.
Now, I don't know about you
Re: (Score:3, Informative)
according to google, essentially NO extra cpu (in real terms) is needed anymore.
citation:
https://www.imperialviolet.org... [imperialviolet.org]
quote:
If there's one point that we want to communicate to the world, it's that SSL/TLS is not computationally expensive any more. Ten years ago it might have been true, but it's just not the case any more. You too can afford to enable HTTPS for your users.
Re: (Score:2)
Re: Worth a shot (Score:2)
I own a web hosting business. I resell certificates. I keep my prices pretty low ($10CAD for Comodo PositiveSSL, $12CAD for RapidSSL). I do this to try to push the notion that you need to encrypt everything. I'm currently planning to start giving them away with hosting packages, when paid annually.
With that said, I really don't care if technology carries us another direction and I lose those sales. I don't really make much on them anyway ($4-5 per cert).
I really like the idea of DNSSEC and DANE. From my und
Re:This is a huge first step! (Score:4, Informative)
re: "They put the inventor of PGP in jail - Phil zimmerman."
Uh, no. He wasn't even charged, just investigated.
Re: (Score:3, Informative)
He did get put in jail, though, on other occasions. Apparently for protesting in a disruptive manner at a nuclear test site.
So technically they were right up until the part where they identified the reason for his arrest.
Re: (Score:2)
Re: (Score:2)
I'm with you on your points, but can you cite when Phil Zimmerman was arrested? He was investigated back in the 90s and it was dropped without an indictment in 96 according to wikipedia.
Re:This is a huge first step! (Score:5, Insightful)
Horseshit.
Some things they just keep secret.
Other things, they commit perjury and perform parallel construction to hide how they got it in the first place.
In other words, they don't need no steenking warrants, they don't need to care about the law, and will do anything they see fit.
They can take care of the pretense of following the law much later.
I'm long past believing they give a damn about needing to prove they obtained stuff legally.
Re: (Score:2)
Re: (Score:2)
Agreed,
I don't see this as much of a solution. The Grandparent is right transport encryption is a requirement but I am not sure its first step. encryption and authentication are part and parcel. One really isn't useful without the other and might be more dangerous alone than nothing.
At least with HTTP I *know* there exists the possibility what I am receiving isn't coming from who I thought it was from, may have been undetectably altered, and others know I am viewing it. Just as anything i send, might be
Re: (Score:2)
They put the inventor of PGP in jail - Phil zimmerman. Reason: simple transport encryption - even without trust - makes Fedzilla and its police state angry.
This would force the Fedzilla police state to obtain end-point warrants rather than be able to sniff the firehose.
I would rather have transport encryption than nothing. Also, even if these are back doored by the NSA, the government would have to prove how they got the information without a warrant.
This is an imperative first step.
I'm just curious here...what exactly makes you assume the government would have to prove a damn thing, even if what they are doing is illegal by our own Constitution?
Not sure what is feeding your delusions, but one thing is for certain. The government needing authority or approval to do anything to you legally or otherwise is complete bullshit.
And this "imperative" step means jack shit if the NSA has already been issued a cert.
Now prove they haven't, and you can have your first step back.
Re: (Score:2)
I expect a lot of agents to come in and stump against transport encryption. I question why on earth you wouldnt want to make it harder to sniff. Even if there is a man in the middle possibility, they need a copy of every cert. Lugging around millions of certs and trying to apply them to every flow to see if you can get into that flow sounds a lot harder than not encrypting.
Re:No thanks... (Score:5, Insightful)
Re: (Score:3)
This.
I think this is the REAL question. As is: why should we believe that https isn't also already compromised (i.e. by the NSA)?
Re: (Score:3)
The transport itself - most likely not. They wouldn't be spending all kinds of time and effort to break into certificate authorities so that they can generate their own "trusted" certificates for whatever websites that they wish.
The notion that there are "trusted" root certificates is where the problem lies. But I have not seen anyone come up with a workable alternative.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Where do you think there's an honest government?
In the country made of honest people.
Re: (Score:2)
They have computers there? Who knew!
Re: (Score:2)
They have a TRS-80 in Pyongyang.
Re:No thanks... (Score:5, Informative)
Re: (Score:2)
Re:No thanks... (Score:4, Informative)
That almost doesn't matter... you create the private key and make a certificate request containing only the public key that they sign, but you're the only one with the private key for that particular certificate with that particular fingerprint. Sure, they or indeed any other CA your users' browsers trust could sign a different certificate and run a MITM, but if they did this in general it would be trivial to discover. Just scribble down your certificate fingerprint and browse it from your family / friends / work / internet cafe / proxy / VPN / open wifi Internet connection and look at the certificate details or just ask some random tin foil hatters to verify it.
It of course doesn't guarantee the government won't do anything nasty if a particular "person of interest" decides to browse your website, but you've at least upgraded it from postcards to an envelope that with a little bit of effort can be steamed open and resealed. Today if they have a bulk logger installed at key internet junctions, which you can be almost certain they do then they can just dump it all to tape, every HTTP call to every website passing through and analyze it later.
Even with the weakest of certificates they must decide whether to intercept it per site, per user and risk their tampering being discovered and it all must be done live. They can't just dump it to tape and decide weeks and months later that they want to go back and look at all that traffic, like postcards passing by a video camera. It would effectively kill bulk traffic data collection and by encrypting URLs also a lot of useful metadata, they'd just see server-to-server connections.
Re: (Score:2)
Its based out of the US and A. As such, I have to assume it is pre-backdoored.
NSA has claimed the right of Prima Podex?
Re: (Score:3, Insightful)
SNI solved this problem
http://en.wikipedia.org/wiki/S... [wikipedia.org]
Re: (Score:3)
More to the point:
All modern browsers except IE on XP or lower support it.
All modern web servers support it. For reference, this is all versions of nginx; Apache 2.2.12+; and IIS8+. Assuming nginx and Apache are compiled against a version of openssl released after 2006 and didn't explicitly disable SNI.
Re: (Score:2)
Re: (Score:2)
A static IP for your shared host is usually cheaper than SSL. However, they're not going to let you use your free SSL and will charge you for their own SSL anyway, because they have the control.
Re: (Score:2)
Who is "they". The VPS I rent is shared (by me) to various parties - shared hosting. It's my VPS. I control its certificate. There is no "they".
Re: (Score:2)
If you can live with Android 2.x and IE on Windows XP being unable to connect, then there is a "hostname" equivalent request, and you can host multiple SSL sites on a single IP.
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
We'll try to give site operators a configurable choice of multiple solutions -- certificates with multiple Subject Alternative Names (SANs); per-site certificates deployed using Server Name Indication (SNI); IPv4 addresses per site if you have enough; or IPv6 addresses per site.
All of these solutions have different problems and limitations:
Re: (Score:2)
For a certain level of technical competence, I suppose that makes sense. But there's a big RAM hit to have a CPanel instance for each customer, so the beginners would save a lot of resources to be on the same server instance.
Re: (Score:3)
SNI is now supported by all the major players (IE was the last hold out) but... I'm pretty sure the current free cert providers don't support it.
SNI requres support from (a) the browser, and is near-universally supported by all browsers these days and (b) the web server, with many hosts supporting it already. If not, they should.
The certificate authority is not involved with SNI at all.
Re: (Score:2)
Slashdot doesn't support utf, it doesn't support ipv6. To config https would be inconsistent then.
Re: (Score:2)
Re: (Score:2)
I think they might do something like this: You run a program on your server. That program establishes an encrypted connection to the Let's Encrypt server (using normal SSL). The Let's Encrypt server sends a secret message over the encrypted channel. The program on your server sets up a web page with that secret on it and sends the URL back to over the encrypted connection. The Let's Encrypt server then accesses the given URL normally, and checks whether it contains the correct secret. If so, it issues a cer
Re: (Score:2)
A) WTF do you mean, "nearly worthless"? It'll mean what it does today: the connection is secured using SSL/TLS. Nothing more and nothing less. HTTPS isn't some special indication that a site is Serious Business or something. It just means that an eavesdropper can't listen in on the connection or intercept the traffic. If you *REALLY* think there's value in that distinction, though, Extended Validation certs (green URL bar) will still exist to take money from people like you.
B) Vaguely possible, but not some