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
Cloudflare? Though i would not advise to use it since they will man in the middle your traffic which pretty much defeats the purpose of having ssl in the first place.
Nope, I'm completely away from Cloudflare.
Thanks!!
https://www.freessl.com/https://www.sslforfree.com/
edit: wrong link edited
It's also a 3 months certificate?
Thanks!!
Quote (from sslforfree) "we generate a private key in your browser".
a) trusting anything in a browser is simply insane
b) they create a private key??? The private key should be from and with the user - the CA should never have it. (But I understand that sslforfree has friendly intentions and wants to help idiots with, you know, "that complicated crypto stuff").
c) ssl isn't really secure anyway. You need it, however, as the browser/CA mafia is on a "ssl only!" hype crusade. It's basically a formality, so let's encrap (or any other cert) is good enough. Basically the real reason one needs a 3rd party cert is that the browser/CA mafia blasts surfers with "not trustworthy!!!" messages when you use a self-signed cert.
cPanel has a partnership with Comodo to generate free certs - there's a bunch of (non-cPanel) hosting providers that do as well
Aren't they using LE or parts from it too?
they are as the site says but i found this with googling no personal experience
My personal experience with lets encrypt is, that if you're not using fancy
management software, it is really really really simple to use, in any way.
I'm not sure if you understand how exactly an SSL certificate works.
It's not about creating a certificate or installing it. That can be done with a few simple commands in your server and they will be as secure as the ones CIA uses, in terms of encryption strength.
Having a browser to acknowledge it without security warnings is the trick. Certificate Authorities create and maintain the certificate verification, and browsers trust them. If the certificate authority becomes untrustworthy, browsers stop trusting them (as it was the case with Symantec and Chrome a few months ago).
This trust is necessary, because without central databases of valid certificates, any hacker can launch a man-in-the-middle attack, replacing your certificate with a fake one, and your users' browsers wouldn't know the difference.
That's why you can't get an unverified certificate to install without showing up warnings in the browser. Central databases (certificate authorities) deal with lots of crap every day and they have several full-time employees, as well as many legal hoops and inspections they need to jump constantly to keep their verified status.
This all costs a lot of money for them, they won't be able to keep it up for free, unless you already have huge amounts of money to burn (Google) and create a free certificate authority and keep.it trusted by all browsers (Let's encrypt). Their motivation for spreading to all webservers and their owner's contact information is probably an evil one, but that's the price to pay if you want a "free" certificate.
yap, they're
COMODO https://www.gogetssl.com/domain-validation/comodo-free-ssl/
@Harzem
Not really. For a start most CA's check pretty much nothing at all. Their testimony is utterly worthless.
The trouble is with the browser/CA mafia who quite arbitrarily decided that only certain CAs are trustworthy and the browsers recognize only those as "trustworthy".
Plus ssl is rotten anyway. This whole ssl/tls game is largely but a big fraudster show.
It's not working perfectly, but that's because of the players involved. Can you recommend a systemic inprovement?
Classical attempt of "If you have no better alternative right now and here, shut up". Sorry, not with me.
"Not working perfectly" - but, so the implication, like 99.9%? Bullshit. ssl/tls is utterly rotten, most configs are mindless and not secure and that will stay that way because it's way too complicated for most sysadmins. Plus the code is utterly rotten and commonly used ciphers are questionable or even known to be nsa tainted.
Oh, and google went after symantec because symantec - a BIG name in the field, after all - had willy nilly given away certs for google. And the very same happens a thousand times every day.
DANE.
And how would that protect me (a Turkish citizen) from my own government who already uses man-in-the-middle intervention to modify DNS requests to block websites they don't like?
DANE assumes requests to the DNS is not modified by the parties in between. DNS requests aren't encrypted. Turkish government freely modifies any DNS request. They would have no problems
How would you secure the DNS requests itself?
With SSL, or a similar central-authority based system.
I get to pick whether I trust my government, my ISP, or a Certificate Authority to secure my connections. I can use self-signed certificates for my own servers, but for other people to trust my website, they need a central authority.
And I will sooner go live in the mountains without internet connection than trust a government-controllable secure transport layer.
If you're putting up with that via using plain DNS and letting it to be MITMed/modified, it's solely your own fault. Get on with a private resolver on a VPS which you would access over a VPN, or the purposely-built resolver protocol i.e. DNSCrypt.
DNSsec would prevent that.
I actually studied cryptography in college.
Most common ciphers aren't NSA tainted by design. Sometimes they hold a competition to declare an official cipher, and there are other ciphers created by independent parties. Those ciphers are impossible to build "backdoors" to them, because they are all visible-source, they usually come with a list of reasons why they were designed that way, and if one of them is flawed, top minds can crack it in an afternoon after learning about it.
The popular ciphers have years and years of cryptoanalysis performed on them by thousands of crypto experts. Some of the ciphers can be deemed insecure, some others stand the test of time.
NSA may have funds to build a supercomputer to brute force certain encryptions, but that's not an everyday occurence and it can be easily surpassed by increasing some variables in the cipher.
NSA doesn't employ magicians, they employ mathematicians, which probably aren't as smart as the top-minds who are already attacking the ciphers in a public manner, and still failing to crack them.
These are all related to symmetrical ciphers.
Then there is RSA cipher, which is and art form that was created by mathematicians. It's one of the most beautiful applications of pure mathematics to real-life, and when aliens from XELDAX-9 find the remains of human civilization 10 million years in the future, I'm sure they will put RSA encryption to the top 10 achievements of the history of human intellect, along with Fourier transform. Of course, at that point, they would have achieved finding prime divisors with quantum computing, so they will crack our SSL certificates in like 2 seconds, but they will still be amazed at how humans were able to create RSA in the first place.
And do I explain this to my 10,000 visitors on my personal blog about making home decorations out of garbage bags? Do they all install their own VPN with DNSCrypt?
Not if my visitors can't even access DNS servers or get unmodified response.
You are taking responsibility from one authority (CAs) and giving it to another authority (DNS providers and ISPs that connect to them). In my case, CAs are the more trustworthy parties.
You mean that they didn't advertise "We have backdoored algo xyz"?
You confuse math and software (with some foss religious belief added). We don't use algorithms, we use software implementations. And plenty studies show that virtually all attacks go against implementation and not the math.
Speculation. Some say that nsa and ghcq have the best (and some factors hint at that), others think they don't. Speculation.
Yes, rsa is elegant - in theory. Practically, however it comes down to using very large prime numbers, which are, in fact probable primes and not certainly primes.
In reality we end up again with flawed or even rotten software.
Also, keep in mind that in finding the probably primes, prngs play a major role. In other words: nsa need not crack rsa; to control or to make you use a weak prng is good enough. And - Tada - that's what nsa actually got cought doing.
Plus, of course, all the other problems with utterly rotten software. Kindly note that tls 1.3 is the fucking first tls version where formal verification is at least tried and work in progress.
You studied crypto? You know math? Then you should know that everything is a hypothesis until verified/proven - and very little in crypto software is formally verified. In fact, most of the code can not even be verified because it's written in an ambiguous language (which again is why the current first tls specification and verification is done in a quite new language that lends itself well to such jobs)
Btw, this whole discussion is extremely optimistic because out there in reality configs are too complex and processor cycles cost money which boils down to: most of it is either poorly standard configured or configured to run as cheaply as possible. Which leads to yet another problem field, namely the DDOSability of ssl services (a request is dirt cheap but the server has to do expensive operations - a classical recipee for ddos).
StartSSL?
https://www.startcomca.com/
They don't need to. Algorithms are designed by civilians, visible-source, and analyzed by other civilians, most of whom aren't even US citizens to be intimidated by NSA. You can't backdoor a publicly used algorithm and get to live with it for more than an afternoon.
And how is that an argument against using SSL certificate system? Any other system designed to replaced "flawed" SSL system will have software, written by people.
Most SSL software is already open source, including the algorithms, browsers, openSSL, etc. If they have flaws, attack on the software, not the theory. If you want to replace SSL system, find a way to use something other than software to implement it, or don't blame the software. You still have to use software, most probably flawed software at that, to replace SSL system with any other system. And when someone attacks the implementation of the new system, it's still be a software problem, which can be improved, as it can be in the current system.
Then we need to create better open-source software, but this discussion isn't about RSA, so I'm skipping this to keep it short.
No reason to believe Next-SSL system will have perfect software. NSA probably got better at implementing backdoors, right? /sarcasm
I too am surprised why this isn't a more common way of DDoS'ing.
"visible-source algorithms". My ass, oh fuck. Yet another (f)oss sectarian who seems to think that being (f)oss somehow magically makes things secure.
nsa already has "backdoored" a publicly used algorithm. Moreover there have been attempts to establish weakened versions of algorithms. And there have been attempts by us of a agencies to have open source developers implement weaknesses or tainted algorithms - that's what we know. You bet your ass there are many more we do not know about (rats don't tend to advertise).
Wrong conclusion. A new system may or may not repeat the errors of the ssl universe.
There it is again. As if "being open source" were equal to "is secure". Pardon me but the holy credos of (f)oss have failed miserably. You want an example? How about: 1000 eyes? Hell, heartbleed happened because there were not even 4 competent eyes.
Even shorter: You are disqualified as you don't really care about security but rather about your sectarian system which has not proven to be secure, quite the contrary.
Well noted, I'm not somehow against (f)oss nor do I think that closed software is somehow per se better. I just had too many discussions with sectarians (of both sides).
You are defending a model that is utterly flawed (proven fact), lousily implemented (proven fact) and has repeatedly failed (proven fact).
Isn't the whole point of SSL to encrypt the data between the user and the server so that a man in the middle cannot scrape off usernames/passwords/credit cards etc? So SSL/TLS is not some "fraud show".
The public certificate thing is to prevent the browser from bitching at you and is theoretically more secure because it uses known trusted public entities. We can argue if that part is some scam or not but the idea behind SSL/TLS is not.
No, but when people are advancing their careers by finding cryptographic attacks against each other's ciphers, they tend to do a better job than failing to find heartbleed.
As you love to say, speculation. You claim software is implemented poorly, you claim nsa puts backdoors in software, yet your solution is prone to exact same errors. What makes your magical new software secure, which can't be implemented in existing system?
Yet, new and totally untested software is expected to be reviewed by more competent eyes? What's stopping those eyes from inspecting existing software?
I'll give you a hint: financial indifference.
I'm orders of magnitude more qualified than you are. Have you even met a cryptoanalyst?
I'm not saying ssl is perfect, but you are living in a dream world where competent people write excellent software for a free system where NSA just stops interfering and decides not try to inject backdoors to the new systems for no reason at all.
Since you are getting hostile and not really responding to my points, I'm going to stop responding, and since you think I'm sectarian (no, I'm just educated in math more than you are), you think I won't change my mind, so I suggest you call it a night too.
Hey @Plioser,
I have some VestaCP installations + custom script to auto update Server certificate (Vesta UI, Exim, Dovecot, FTPd) and all work like a charm. Other domains + LE seem to be stable for many-many months now.
I don't know any other CA to offer free certificates, apart from the now defunct StartCom. I'd suggest you give VestaCP another try... ?
I sure hope they are gone. PiTA to setup, even more of a PiTA to renew, and just barely better than self generated. They were my first experience with public SSL. I am still traumatized.
The OpenSSL guys had critical bugs in their code for years before anyone noticed. If no one noticed that, what makes you think they'd noticed any backdoor?
Just because something is public/open source does not mean it's safe. It means it can be reviewed by anyone. Those are not the same things and we shouldn't operate under the premise that they are.
Theory. There have been mitm attacks, even ones using valid certs.
The problem with certs and CAs is (imo) that CA sell something they often do not deliver and that people accept that because a) most don't understand crypto and b) they have to; if, say as a business owner, you don't want warnings pop up you'll pay a CA for a cert, period.
Another problem is that because CAs don't do their job there may be multiple certs for a site and a users browser can't know which is the right one. There have been attempts to fix that (e.g. pinning) but a) that evident problem wasn't properly considered (if at all) in the beginning and b) there is no generally accepted and standardized structure in place.
I'll end with another "funny" example: For quite some time pretty much everybody could get a valid certificate for any site (incl. for example, google.com) due to not only lousy but on top of that different interpretation of a string in the browser and at the cert.
Somewhat simplified the problem was that the CA parsed the string from the end (seemed to make sense for them) while the browser parsed it from the beginning ("normal" string parsing). Such it was possible for many years to request a cert for domain A (seen from the browser who accepted it) under the name of domain B (of which the evil guy was the true owner). In effect he did, for example, create a request that, seen from the CA, seemed to ask for a cert for evil.org, which however, seen from the browser actually was for google.com.
TL;DR Basically certs serve mainly 1 real purpose (which is also the reason why many buy/get them), namely to not have the users browser complain.
As for real security, oh well, that's pretty much a funny lottery (of CA and browser version and ssl/tls lib and version).
No, I don't claim. ssl is lousily implemented and nsa did put backdoors into/tainted software and algorithms. Don't confuse facts and "claims".
As for "my magical new software" you have left the realm of reality and entered phantasizing. I didn't introduce any new system of mine.
Bullshit. 90% of "open source" work, at least in non trivial projects, is done in "financial indifference" only superficially. Most of those people work either for large corps or in academia. The second pair of eyes who failed to spot heartbleed, for example, works in academia.
Another, more positive, example (of many more) is Prof. Bernstein who produces open source, is however doing that in his payed job and with diverse grants. Actually pretty much all good crypto has been/is done by payed people.
You can't nail competence or integrity simply to "financial indifference".
I thank you for that amusement, Mr. 2 years college crypto.
Btw. while you design web sites I actually work in IT security, actually write formally specified, modelled, and verified code. Thanks again for the good laugh and happy web-site colouring!
Hi @Elmo.
In fact, I'm quite happy with VestaCP. My problem is that I have some hardcoded changes in the Nginx config files and VestaCP rebuild these files in every renovation. So, I have to do the changes again every time.
I have to see if modifying the templates could I solve the problem, but if I could find another option for a free certificate, I prefer.
Thanks!!