Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with OpenID
Advertise on LowEndTalk.com

In this Discussion

Apart from Let's encrypt, what other options exist to obtain free SSL certificates?

Apart from Let's encrypt, what other options exist to obtain free SSL certificates?

Hello.

My history with Let's encrypt + VestaCP is "traumatic" and I'm looking for other options to obtain a free SSL certificate for my own personal web.

Any recommendations?

Thanks.

«1

Comments

  • mkshmksh Member

    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.

    Thanked by 1Plioser
  • mksh said: Cloudflare?

    Nope, I'm completely away from Cloudflare.

    Thanks!!

  • perryoo11perryoo11 Member
    edited October 12

    |post4vps| for a free vps for your developement| me |

    Thanked by 1Plioser
  • @perryoo11 said: https://www.sslforfree.com/

    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.

    My favourite prime number is 42. - WSS has kidnapped a digit from Pi!

    Thanked by 2Mridul Maounique
  • ZerpyZerpy Member

    cPanel has a partnership with Comodo to generate free certs - there's a bunch of (non-cPanel) hosting providers that do as well

  • @perryoo11 said: https://www.freessl.com/ https://www.sslforfree.com/

    edit: wrong link edited

    Aren't they using LE or parts from it too?

  • @Timtimo13 said:

    @perryoo11 said: https://www.freessl.com/ https://www.sslforfree.com/

    edit: wrong link edited

    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

    |post4vps| for a free vps for your developement| me |

  • 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.

    HarzemDesign and FraudRecord I have these.

    Thanked by 1steny
  • @Timtimo13 said:

    @perryoo11 said: https://www.freessl.com/ https://www.sslforfree.com/

    edit: wrong link edited

    Aren't they using LE or parts from it too?

    yap, they're

    @Plioser said:

    COMODO https://www.gogetssl.com/domain-validation/comodo-free-ssl/

    Thanked by 1Plioser
  • @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.

    My favourite prime number is 42. - WSS has kidnapped a digit from Pi!

  • It's not working perfectly, but that's because of the players involved. Can you recommend a systemic inprovement?

    HarzemDesign and FraudRecord I have these.

  • @Harzem said: 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.

    My favourite prime number is 42. - WSS has kidnapped a digit from Pi!

    Thanked by 1AlexJones
  • @Harzem said: It's not working perfectly, but that's because of the players involved. Can you recommend a systemic inprovement?

    DANE.

  • @Middling said: 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

    1. creating a fake DNS entry for Gmail servers
    2. Creating a fake Gmail website with modified DANE
    3. Spying on everything I type on Gmail.

    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.

    HarzemDesign and FraudRecord I have these.

  • rm_rm_ Member
    edited October 12

    Harzem said: 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?

    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.

    Harzem said: creating a fake DNS entry for Gmail servers

    DNSsec would prevent that.

    Thanked by 1Maounique
  • bsdguy said: commonly used ciphers are questionable or even known to be nsa tainted

    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.

    HarzemDesign and FraudRecord I have these.

  • HarzemHarzem Member
    edited October 12

    rm_ said: 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.

    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?

    rm_ said: DNSsec would prevent that.

    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.

    HarzemDesign and FraudRecord I have these.

  • @Harzem said:

    Most common ciphers aren't NSA tainted by design.

    You mean that they didn't advertise "We have backdoored algo xyz"?

    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

    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.

    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.

    Speculation. Some say that nsa and ghcq have the best (and some factors hint at that), others think they don't. Speculation.

    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, ...

    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).

    My favourite prime number is 42. - WSS has kidnapped a digit from Pi!

    Thanked by 1Maounique
  • bsdguy said: You mean that they didn't advertise "We have backdoored algo xyz"?

    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.

    bsdguy said: we use software implementations. And plenty studies show that virtually all attacks go against implementation and not the math.

    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.

    bsdguy said: 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.

    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.

    bsdguy said: Plus, of course, all the other problems with utterly rotten software.

    No reason to believe Next-SSL system will have perfect software. NSA probably got better at implementing backdoors, right? /sarcasm

    bsdguy said: namely the DDOSability of ssl services (a request is dirt cheap but the server has to do expensive operations - a classical recipee for ddos)

    I too am surprised why this isn't a more common way of DDoS'ing.

    HarzemDesign and FraudRecord I have these.

  • @Harzem said:

    [bsdguy said]... backdoored ..."?

    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.

    "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).

    bsdguy said: we use software implementations. And plenty studies show that virtually all attacks go against implementation and not the math.

    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.

    Wrong conclusion. A new system may or may not repeat the errors of the ssl universe.

    Most SSL software is already open source,

    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.

    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.

    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).

    My favourite prime number is 42. - WSS has kidnapped a digit from Pi!

  • edited October 12

    @bsdguy said: @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.

    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.

  • @bsdguy said: "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.

    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.

    @bsdguy said: Wrong conclusion. A new system may or may not repeat the errors of the ssl universe.

    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?

    @bsdguy said: Most SSL software is already open source,

    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.

    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.

    @bsdguy said: 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.

    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.

    HarzemDesign and FraudRecord I have these.

  • ElmoElmo Member

    @Plioser said: Hello.

    My history with Let's encrypt + VestaCP is "traumatic" and I'm looking for other options to obtain a free SSL certificate for my own personal web.

    Any recommendations?

    Thanks.

    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... ?

    Thanked by 1Plioser
  • edited October 12

    @Elmo said:

    the now defunct StartCom

    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.

    Thanked by 1MasonR
  • @Harzem said: You can't backdoor a publicly used algorithm and get to live with it for more than an afternoon.

    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.

  • bsdguybsdguy Member
    edited October 12

    @LosPollosHermanos said: 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.

    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).

    @Harzem said: 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?

    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.

    @bsdguy said: Most SSL software is already open source,

    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.

    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.

    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'm orders of magnitude more qualified than you are. Have you even met a cryptoanalyst?

    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!

    My favourite prime number is 42. - WSS has kidnapped a digit from Pi!

  • @Elmo said: 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... ?

    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!!

  • HarzemHarzem Member
    edited October 12

    @bsdguy said: 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!

    I'm a software engineer with a master's degree in the field an 17 years experience in writing encryption routines and software. I wrote my own symmetrical cipher in 2001 and presented to a small board of cryptoanalysts in university. What were you doing back then?

    Be careful with who you are attacking at. I'm coloring websites for a quick $5000.

    HarzemDesign and FraudRecord I have these.

  • ZerpyZerpy Member

    I'm running out of popcorn guys.

  • HarzemHarzem Member
    edited October 12

    @JustAMacUser said:

    @Harzem said: You can't backdoor a publicly used algorithm and get to live with it for more than an afternoon.

    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.

    An algorithm here is less than 100 lines of code, a mathematical definition of a cipher. You can't put a backdoor to it and get to live with it.

    OpenSSL is a software which implements many routines, and even if it's open source, it can have bugs, some of them very critical, and overlooked.

    AES, an algorithm, has its entire definition in this 2 minute read: http://imps.mcmaster.ca/courses/SE-4C03-07/wiki/siaa/se4c03_aes_wiki(7).html

    A software implementation the size of OpenSSL, on the other hand, requires months of testing before it can even be considered "ready for beta".

    My own fraudrecord uses a custom hashing algorithm :

    FUNCTION fraudrecord_hash ( value ) FOR 32,000 TIMES LOOP value = "fraudrecord-" + value value = SHA-1( value ) END LOOP RETURN value END FUNCTION

    I can't put a backdoor here, but I can put a backdoor to the software implementation, or have bugs in the implementation that may go unnoticed for years (even if it was open-sourced).

    Open-source software may be utter shit, they have proven to suck hundreds of times before. Open-source (visible source) cipher algorithms don't have that problem, it's a mathematical definition, which are regularly attacked and tested. They may have bugs (that reduce security), but not backdoors. Those bugs are easily identified by third party academics.

    HarzemDesign and FraudRecord I have these.

  • @Harzem said:

    @bsdguy said: 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!

    I'm a software engineer with a master's degree in the field an 17 years experience in writing encryption routines and software. I wrote my own symmetrical cipher in 2001 and presented to a small board of cryptoanalysts in university. What were you doing back then?

    Be careful with who you are attacking at. I'm coloring websites for a quick $5000.

    17 years? WOW! Now I'm impressed and frightened.

    What I was doing back then? I was scratching my balls and thinking about the decade I had already spent in the field and about some of the students whom I had teached, advised, and navigated through their thesis work.

    Have a nice night

    My favourite prime number is 42. - WSS has kidnapped a digit from Pi!

  • Then our heads are thick enough not to share the same opinion on the matter, after all this time. Farewell to you too, sir.

    HarzemDesign and FraudRecord I have these.

  • You guys should make love tbh...

    European NOC legally registered - Providing Server/Cluster Management Solutions

    Design & IT Company - We deliver within the EU!

  • emgemg Member
    edited October 12

    Like others, I have been reading the debate between @Harzem and @bsdguy (and others) with interest. I do not generally disclose personal information in a forum like this, but suffice it to say that I may know a little something about what they have been discussing here. I have met a cryptanalyst. :-)

    I do not want to join in the detailed debate and make pedantic corrections.

    I will publicly state that Harzem has written many apparent "statements of fact" which are not true. In my opinion, Harzem's statements do not align well with his assertions about his crypto qualifications. Harzem may have "studied cryptography in college," but I am sorry to report that the lessons may not have sunk in as well as Harzem believes. It surprises me, because I respect Harzem and his overall skills and abilities, which don't seem to align well with his erroneous assertions and statements.

  • Interesting discussion @Harzem & @bsdguy - is there a real need to show who's got the bigger dick degree / experience though? Might be entertaining to some, I reckon.

    Anyway, what do you guys think of libressl? Really worth it to consider rather than openssl?

    Back on topic, @Plioser since startcom / wosign aren't recognized by most browser (and that's not necessarily a bad thing, even though the CA system seems to be rotten/broken by design - not sure removing those certs changes anything, even if it helps keep the trust in the CA system) I didn't find any alternative better than let's encrypt or cpanel free cert if you're on a cpanel system, as far as I know there is no more long term (> 3m) free cert validated by a "proper" (whatever that means) CA.

  • HarzemHarzem Member
    edited October 12

    @emg I've been mostly simplifying and generalizing my statements to fit in the narrative of this forum. There are exceptions to everything, and I'm aware of some of them. However I'm defending the theoretical safety of the algorithms, while my opponent is defending the practical implementation problems.

    I don't think anyone will gain anything with discussing it publicly any further, but I can discuss in more detail via PM about specifics if you like. I might even learn something from you.

    HarzemDesign and FraudRecord I have these.

  • Harzem said: Open-source software may be utter shit, they have proven to suck hundreds of times before. Open-source (visible source) cipher algorithms don't have that problem, it's a mathematical definition, which are regularly attacked and tested. They may have bugs (that reduce security), but not backdoors. Those bugs are easily identified by third party academics.

    I think you're just nit-picking semantics here. The NSA (as previously mentioned by @bsdguy) has been shown to intentionally introduce "bugs" or weakenings into open source software and "algorithms" thereby allowing them a backdoor into said information.

    My point was that you argued by having things open source we have the surety that it will not go unnoticed:

    You can't backdoor a publicly used algorithm and get to live with it for more than an afternoon.

    That is simply not the case, regardless of word choices or whatever is being referenced as "open source". Something being open sourced is by no means a surety of anything.

  • HarzemHarzem Member
    edited October 12

    JustAMacUser said: Something being open sourced is by no means a surety of anything

    Open source software can suck big time. They can be full of security holes, some of them may go unnoticed for years, and they may cause big data breaches. OpenSSL had this problem, wordpress had this problem, they are almost never fully secure.

    I'm not implying open source software is secure.

    Open source cipher algorithm is not an open source software. It's a mathematical definition, a little more than multiplication and division. They are much easier to test for and identify bugs, backdoors, and shortcomings.

    Implementing those algorithms, as in OpenSSL's case, is a software problem, and open-source doesn't fix that.

    NSA can't put a backdoor into AES algorithm, but it can put a backdoor into an SSL software that uses the algorithm. This isn't nitpicking. They are completely different things.

    HarzemDesign and FraudRecord I have these.

  • You are nitpicking. Let me show you:

    You can't backdoor a publicly used algorithm and get to live with it for more than an afternoon.

    Emphasis mine to show that you stating by publishing something publicly an individual or entity cannot "get away" with it.

    They [open source cipher algorithm] are much easier to test for and identify bugs, backdoors, and shortcomings.

    Ease of identifying is not ensured by having something be open source. Again:

    You can't backdoor a publicly used algorithm and get to live with it for more than an afternoon.

    Why? Why does having it published publicly equate to identifying flaws? There's a cause and effect disconnect here. Just because something is public does not mean its perfection or lack thereof will be acknowledged.

  • HarzemHarzem Member
    edited October 12

    JustAMacUser said: Why? Why does having it published publicly equate to identifying flaws?

    In the rest of my comments, I specifically wrote "visible source algorithms", which meant their mathematical functions were publicly released, but some of them don't have open licenses to be used freely.

    In the quote you mentioned, I apparently wrote, mistakenly, "publicly used algorithm" instead of "publicly released algorithm". If you read the rest of my comments, you'll see I'm talking about releasing the algorithm details, not how much it's used. That was my typo, written in haste.

    A publicly released cipher algorithm, if not released by someone like me but released by someone like Bruce Schneier or NSA, is analyzed to its bones and ashes by the whole crypto-community.

    For example, MAGENTA algorithm, one of the AES contestants, was found to have weaknesses in a matter of hours.

    Another one, Dual EC DRBG, was known to be insecure, because you can't hide a backdoor in a cipher algorithm, if you do, you'll get caught. This one is an interesting read, it shows how you can't hide a backdoor and get away with it.

    These are all visible source, so they are analyzed by crypto experts easily.

    By the way, this "Dual EC DRBG" is the algorithm NSA tried to put in a backdoor, and now is used by no-one.

    HarzemDesign and FraudRecord I have these.

  • FalzoFalzo Member

    @Elmo said: custom script to auto update Server certificate (Vesta UI, Exim, Dovecot, FTPd)

    would you mind sharing this? I never took the time to write something together, yet it would be of great help ;-)

    Netcup DE KVM specials: 1vC 1GB 18,88€ or 4vC 4GB 42,88€ yearly with 5€ off 1st order: 36nc15066114490 / 36nc15057512401 UltraVPS.eu KVM in US/NL/DE, 15% off 6months: 1GB & HDD from 2,55€ or 2GB & SSD from 3,83€

  • ElmoElmo Member

    @Falzo said:

    @Elmo said: custom script to auto update Server certificate (Vesta UI, Exim, Dovecot, FTPd)

    would you mind sharing this? I never took the time to write something together, yet it would be of great help ;-)

    Sure thing! Take a look here https://github.com/ifaist0s/vesta-server-ssl-cert Questions and Feedback welcome, but let's not hijack this thread. Just message me here or in GitHub

    Thanked by 2MikePT Falzo
  • bsdguybsdguy Member
    edited October 12

    @datanoise said: Anyway, what do you guys think of libressl? Really worth it to consider rather than openssl?

    Yes. While I do certainly not consider libressl to be a good solution (which ssl/tls just can not be) it's clearly much better than openssl. Two reasons (among more): the openbsd guys have consistently shown a high regard for safety/security as well as good coding (well, as good as C coding can be). Second reason: simplicity/less complex. libressl has thrown out heaps of gruft and crap in openssl.

    @Harzem said: Open source cipher algorithm is not an open source software. It's a mathematical definition, a little more than multiplication and division. They are much easier to test for and identify bugs, backdoors, and shortcomings.

    Pardon me but you rapidly lose credibility. To quote Dijkstra: "software is the implementation of algorithms". Anyone having looked at crypto implementations will confirm that. The implementation of a crypto algorithm is basically just a transformation between notations with minor adaptations.

    Both are usually very difficult to verify and there are many cases where the algorithm is, in fact, more difficult to verify than the implemention (i.a. because algos typically have a domain like N whereas software has a limited domain which often is even further limited for some pragmatic reason). On the other hand we have (nowadays) better tools to spec, model, and verify algorithms (Btw. a fact that seems to have completely escaped you. No professional would just code an algorithm and similarly mathematicians typically model their algorithm during design, explore domains, etc. I, for example, often work with prolog for domain exploration, then with a formal modeller (yet another "language"), before I finally implement the algorithm in a third language).

    NSA can't put a backdoor into AES algorithm, but it can put a backdoor into an SSL software that uses the algorithm. This isn't nitpicking. They are completely different things.

    nsa already did taint algorithms and they already did try to get a weakened AES spec into the standards. Moreover, just have a look at fips, nist (read: nsa) algorithms, e.g. curves, pretty much dominate major parts of the crypto universe.

    Another one, Dual EC DRBG, was known to be insecure, because you can't hide a backdoor in a cipher algorithm, if you do, you'll get caught.

    Yes, after years and wide usage. Btw. it took many large organisations months and even years to switch to another algorithm.

    A final example to show what we talk about: one can with a ridiculously small amount of samples (say with a days worth of mirrored sessions) deduce with quite high probablity which ssl library is used. The reason: Small but obvious biases and bad random.

    My favourite prime number is 42. - WSS has kidnapped a digit from Pi!

    Thanked by 1datanoise
  • HarzemHarzem Member
    edited October 12

    bsdguy said: Yes, after years and wide usage. Btw. it took many large organisations months and even years to switch to another algorithm.

    Yet the insecurity was identified very very early after the first release.

    Then NSA insisted organizations must use a specific implementation of the algorithm, which was known to be backdoored, but NSA wouldn't grant those organizations necessary licenses if they changed the values in the algorithm to a secure set, so they had to use the backdoored version not to lose their business. In the mean time, NSA bribed RSA to use the backdoored version, while independent critics shouted about the implementation to be insecure.

    It was a huge drama, but it was an implementation problem, not an algorithmic problem. You could have changed two values from the algorithm and it would be secure, and this fact was identified at very early stages. NSA didn't allow people to change the values if they wanted to keep doing business.

    Software sucked, people sucked, people who insisted on forcing a specific backdoor version sucked, people who knew it was backdoored (because that fact was revealed early) but kept using it because of $$$ sucked.

    But the algorithm, with free to pick values, didn't suck. Algorithm with specific trojan values sucked big time, but it was identified very early, not years after it was used widely.

    The whole drama proves my points, afaic.

    HarzemDesign and FraudRecord I have these.

  • MikePT said: You guys should make love tbh...

    Formally verified love.

    Harzem said: Most common ciphers aren't NSA tainted by design.

    I'm inclined to believe that, but I acknowledge there's an element of belief there. We don't know the extent of the NSA's capabilities, and there is an excellent, well-known case where they did backdoor perhaps the most prominent cipher in American history using technology that wasn't known in the public until 20 years later: DES's S-boxes.

    Yes, they were modified to prevent differential cryptanalysis and so strengthened the cipher. Let's take the gov't's word that this is all those S-box changes did. It's still a case of NSA being decades ahead. Are they still? Probably not, but...well, there's that element of faith.

    It's also worth noting that DES was neutered from a larger recommended key size on NSA's request. They couldn't get away with anything that crude in AES but still...it's obvious if they could, they would.

    My Advice: VPS Advice

    For LET support, please click here.

    Thanked by 1MikePT
  • @raindog308 said:

    Harzem said: Most common ciphers aren't NSA tainted by design.

    I'm inclined to believe that, but I acknowledge there's an element of belief there. We don't know the extent of the NSA's capabilities, and there is an excellent, well-known case where they did backdoor perhaps the most prominent cipher in American history using technology that wasn't known in the public until 20 years later: DES's S-boxes.

    Yes, they were modified to prevent differential cryptanalysis and so strengthened the cipher. Let's take the gov't's word that this is all those S-box changes did. It's still a case of NSA being decades ahead. Are they still? Probably not, but...well, there's that element of faith.

    It's also worth noting that DES was neutered from a larger recommended key size on NSA's request. They couldn't get away with anything that crude in AES but still...it's obvious if they could, they would.

    There is an elephant in the room many don't see. It's nist and fips.

    And that's also why "most" algos aren't that relevant. Sure, you and me and Harzem can use whatever we please but state agencies, banks, insurers, large corps - i.e. exactly the kind of organisations with massive data of/on us the citizens - are (partly self-)bound to use only fips approved nist algos.

    And Harzem is wrong again insofar as e.g. nist curves can be - and are - tainted and there are multiple crypto experts and groups out there who pointed at tainted nist curves (where "tainted" typically means that a given curve is computationally weak and/or that it has properties that strongly suggest that a knowing party (nsa) can have very significant computational advantages).

    One ugly side of that is both, those nist curves and, say, djb's 25519 are "ECC" so unsuspecting users (read: 99.9%) just hear "ECC" and have heard about the excellent security of ECC and just use it with whatever curve happens to be proposed; it's only very few users who know that 25519 based ECC is secure while nist curve based ECC is between utterly smelly and simply rotten.

    Another point that is important but often not seen is that, yes, cryptologists and cryptanalysts do rattle, shake and test new algorithms. However, and that's the dirty little thing, those tests are largely of a mathematical nature with only relatively standard computational tests thrown in (like side channels). What they don't do, however, simply because they can't is to run very high powered computational tests. Even universities hardly have the kind of computational power the likes of nsa and gchq have.

    Another factor to keep in mind is the question based on what an Eve (evil party) acts. One should keep in mind that nsa and friends are in the position to be the max. dolev-yao Eve and hence a new level of complexity - and attack surfaces - arises. Example nonce-less sym. encrypted packet transmissions can be cracked much easier if one has access to a couple of billion packets (which is one dolev yao factor) and the computational power to work on them (hence, hint: always use nonces; if no such algos are available, add at least a (good quality!) random integer to each packet).

    This is particularly ugly considering that many protocols have often (or even always) repeating bitstrings (typ. in the handshake, establishment, and key exchange/setup phase). So if Eve has access to the wire - as nsa does - your super duper crypto might actually turn out to be much weaker than you think. The good news is that we nowadays have software that can check protocols (incl. against a max. DY Eve); the bad news is that even some major security projects don't do those protocol tests.

    I'll close with something funny: The ghost cipher the russians used for decades was/is pretty much a sibling of des; the two are very similar. But: the russian one held and still holds while des is considered broken. Reason: the russian designed for security while nsa designed for having a computational advantage ("backdoor").

    My favourite prime number is 42. - WSS has kidnapped a digit from Pi!

Sign In or Register to comment.