New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
FYI - Let's Encrypt Stats
https://letsencrypt.org/stats/
I am gonna deploy it, it is in my short list for the holiday activities.
For the doubt about the SSL, SSL is not a pad lock, it is about:
It's not evil.
But it is incredibly lame, just like the entire Let's Encrypt project.
That project really can't go down in flames fast enough, though it probably won't because people will embrace lame in exchange for free.
The above is nicely provided by self-signed certificate, which can easily make nowadays any monkey, with basic knowledge of how to type on keyboard. Let alone people able to use brains. Surprise: it also costs nothing!
However, self-signed one will either raise a sequence of frightening warnings from browsers/whatever else using them, or even result in the browser refusing to connect altogether.
In the end, this is padlock sign, acceptance by major browsers - the false feeling of safety.
When StartSSL first launched, they were blocked. But now it's okay...
No, self-signed certificate does not prevent MitM attack by ISP or proxy server even if the user is reckless enough to ignore the warning.
Well a self signed certificate in combination with certificate pinning would make mitm attacks very unlikely.
Sorry, but you are missing some crucial understanding here of how SSL/TLS works.
While there are big issues with the CA system, it is not a pointless exercise - a self-signed certificate is not verifiable as being signed by the domain owner, which means you can trivially MITM a connection by just serving up a false cert. Your users would be none the wiser. With a CA-signed certificate, you get a weak assurance that it is the legitimate certificate.
While certificate pinning is useful, it does not fully solve the issue. If a malicious certificate is served upon first contact, you can still be trivially MITMed.
EDIT: By the way, there has finally been a response from the Let's Encrypt team to the certificate duration concerns. The thread can be found here.
O'RLY? I recommend not assuming how other people think or what they know.
It's not that hard to simulate one's own CA and make sure MitM attacks are very unlikely in case of self-signed certificates. So the argument isn't counted. If I introduce secure way to offer my own CA root, no attacks would be efficient.
I can't stop LOL when eva2000/centminmod reply to someone on LE, he (almost) show link to centminmod.com. twitter too?
Which is only applicable in a very narrow set of usecases; namely, when you either control the client systems or can convince every single one of your users to install the root certificate and distribute it over a secure channel.
The point of the CA model is to validate certificates without pre-existing knowledge of what the valid certificate is, and without a secure channel, which is the majority of usecases. No amount of self-signed certificates is going to resolve that issue.
EDIT: And if you can install root certificates, then you wouldn't be seeing any warning pages to begin with, making your entire argument moot.
Tick tock. Tomorrow is Dec03 boys and girls.
Major sponsors are currently Mozilla, Akamai, Cisco, Electronic Frontier Foundation, IdentTrust, Internet Society, Shopify, American Library Association, etc. The list has grown recently.
Yea...clearly it's smothered in fail sauce!
Maybe ease off on the herb?
But the CA model does require a secure channel at some point -- specifically, for getting the CA root certificates at the outset (i.e., browser download must be secure). Self CA has no additional constraints.
Oh noezzz. Pre-Beta software that is "horrible". Shocking!
It's possible for something to be hugely popular and still be hugely lame.
"it probably won't because people will embrace lame in exchange for free."
Ah, your mind, so blank and inexperienced. Yes, beta software may be quite solid and easy to use.
CACert shows that secure channels aren't that hard to provide
Right. But then will those coming with something better have any chance? We will see..
Today is the 3rd Dec and nothing happened, yet. Let us see when it will be a open beta. Still waiting for another excuse to move it away maybe to next year.
@sman you's actin like you off the molly. You need to stop drinking that lean boy before you get hit. Oh and @Nekki still needs to know about the basement.
lol, coming from someone who endorses evobrust............
Public beta is scheduled begin at 6 PM GMT. See http://letsencrypt.status.io/
Yes. This is generally the installation image for the OS, which ships with either a list of CAs, or a key for vendor-provided updates to the CA list, or both.
No. CA lists are normally maintained on an OS level.
It does. You cannot rely on OS vendors to distribute your key.
What are you talking about? CACert is a certificate authority (that is untrusted by all major vendors, I might add), and does nothing to inherently solve the problem of a secure channel.
You can somehow use gogetssl's API to make a 3 month SSL cert for free?
Lmfao.
Quote be based on my sig, real nice. So if I put your name in my sig, does it mean that people hate you should quote me 24/7 just cuz of that?
Go see a doctor if you need meds, or go get some sleep. You clearly are paranoided.
So I got excited about trying LetsEncrypt out today and I've just realised their required client software only supports Debian at the moment...
Fixed that for ya.
I have some bad news for you unfortunately.
https://community.letsencrypt.org/t/lets-encypt-enters-public-beta/4993
One might believe that if they didn't RTFM. I guess it all depends on what you mean and what they mean by "support".
https://letsencrypt.readthedocs.org/en/latest/intro.html
It should "support" any Linux OS that runs apache 2.x.
read the manual works on various OS distributions https://letsencrypt.readthedocs.org/en/latest/using.html#installation for client install itself. However, the authentication methods available some are indeed tailored to debian/ubuntu. For other OSes you can use standalone, manual or webroot authentication modes in LE client. For CentOS i use LE client's webroot authentication for integration into my CentOS based Centmin Mod LEMP stack.
Oh and if official LE client doesn't work for you, there's a list of other LE client implementations at https://community.letsencrypt.org/t/list-of-client-implementations/2103/
aaaaaaaaand there, history has been made the first ever IPMI with SSL
Ah fair enough, the documentation implies otherwise: