Howdy, Stranger!

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


Let's Encrypt Wildcard Certificates Coming in January 2018 - Page 2
New on LowEndTalk? Please Register and read our Community Rules.

Let's Encrypt Wildcard Certificates Coming in January 2018

24

Comments

  • joepie91joepie91 Member, Provider

    stefeman said: I do get your point, but we are fucking the comma here. Take Nordea.fi for example.. If there is a domain Nordeaa.fi with exactly the same website with clear intention of using the SSL to represent the original site, would it not be justified to revoke that certificate because of the sole reason of intended abuse even if DV only assures the validation of Nordeaa.fi and should not be hold as related to Nordea.fi

    No. Nordeaa.fi and Nordea.fi are two different domains. Again: this is out of scope for TLS. If somebody is trying to mimick domains, then the party handing out the domains is responsible for dealing with this.

    Thanked by 2Fidde nulldev
  • bsdguybsdguy Member

    It might be helpful to remember what ssl and certs (which are 2 different, albeit related things) actually were and are.

    • ssl was and is a collection of crypto algorithms and protocols. And: ssl is a clusterfuck; much of it is badly designed and badly implemented and the same goes for quite some core algorithms like for instance rsa. In particular note that pretty much all prime related crypto in ssl actually does not work with primes but rather with numbers that are probably prime.
      How bad is it? Bad enough for heartbleed to happen, for the nsa successfully smuggling a rotten random generator (which pretty much weakens all crypto), and for researchers (and evil people) being capable to identify with quite high confidence which library any given program (like ssh) uses because the implementations are so divergent.

    • certificates are about stating that a given system, typ. a server or a domain, is "certified" by some third party to belong to a certain legal entity (person, company, ...).
      It is important to note that the usual explanation is only a part of the story, namely to assure a connecting entity (e.g. a client browser) that the system he connects to actually is who it claims to be. The other and very important part is attribution and traceability, i.e. to establish a clear link between a domain or system and an "owning" legal entity as well as being sure about the legal entity.

    One hint to that part is in the marketing material of cert. dealers who actually betray everyone by playing as if EV was something special on top. Well, it is not; it is what certs were all about. The real - but usually largely ignored - obligation of cert. dealers would be to check that a) owners is who he claims to be (e.g. by checking relevant documents) and b) owner actually is the owner of a given system or domain.

    It should therefore be clear that LE, and to a large degree commercial cert. dealers, do not give you what's needed. Except for EVs (and I wouldn't bet much on that either) certs - in the best of cases - show that someone was/is in control of the domain and/or server at some point in time (or at least succeeded to convince some cert. dealer or LE of it).

    The two caveats with LE are: a) they are all but worthless and even worse than cheap dealer certs (who at least have some kind of payment info, whose worth, of course, often is low). Both dealer DV certs and LE certs are basically but a formality (and usually also obtained for that reason ("to somehow have ssl stuff working without warnings")). b) with LE you basically open a backdoor for them on your system.

    Important side note: There is reason to believe that LE is in bed with the cert and browser mafia.
    They have serious money, support, and big names behind them and would certainly have the clout to do some real repair of the utterly cert. clusterfuck - but they didn't. They did not make the wen more secure but they chose to keep the rotten system completely unchanged and to just turn one screw, namely price. It is noteworthy that the power behind LE could as well have fought for acceptance of self signed certificates (which are absolutely no less trustworthy than LE certs) but chose not to.

    So, with LE you get the same (or worse) shit than before but - and only that's the difference - you get it for free. One might say "just like advertisements and spam. That's also crap but free".

    What would be desirable? One example would be to link certs to the one place that actually can make a statement about domain ownership, namely the registries. All that would be needed were a single new field in the domain record, namely e.g. the domains public key.

  • joepie91joepie91 Member, Provider
    edited July 2017

    Oh man, so much bullshit in that post, where to begin...

    bsdguy said: ssl was and is a collection of crypto algorithms and protocols. And: ssl is a clusterfuck; much of it is badly designed and badly implemented and the same goes for quite some core algorithms like for instance rsa. In particular note that pretty much all prime related crypto in ssl actually does not work with primes but rather with numbers that are probably prime. How bad is it? Bad enough for heartbleed to happen, for the nsa successfully smuggling a rotten random generator (which pretty much weakens all crypto), and for researchers (and evil people) being capable to identify with quite high confidence which library any given program (like ssh) uses because the implementations are so divergent.

    This conflates a million different things, that are at best loosely related.

    • Heartbleed: This was a memory-related implementation bug in OpenSSL. It had absolutely nothing to do with SSL as a protocol (which, by the way, has been deprecated and superseded by TLS), nor any of the cryptographic aspects of it. It's your everyday missing OOB check, except because it existed in a TLS library, it could potentially expose key material.
    • Random number generator backdoor: This presumably refers to Dual_EC_DRBG, which is neither an inherent part of SSL/TLS, nor of RSA. It was required by NIST standards, but not widely deployed.
    • Divergent implementations being detectable: Yes, this is likely true, and is true for just about every piece of software. That in and of itself is not a problem.

    You mention that "much of [SSL] is badly designed and badly implemented and the same goes for quite some core algorithms like for instance rsa" - however, at no point do you actually explain why you believe that is the case, and none of your examples address this either.

    This is just throwing a lot of impressive-sounding terms onto a pile in the hopes that you sound knowledgeable; I detect no sound technical rationale here.

    (EDIT: I only just realized you mentioned SSH there. SSH doesn't even use SSL, what are you going on about?)

    bsdguy said: certificates are about stating that a given system, typ. a server or a domain, is "certified" by some third party to belong to a certain legal entity (person, company, ...). [...] The other and very important part is attribution and traceability, i.e. to establish a clear link between a domain or system and an "owning" legal entity as well as being sure about the legal entity.

    One hint to that part is in the marketing material of cert. dealers who actually betray everyone by playing as if EV was something special on top. Well, it is not; it is what certs were all about. The real - but usually largely ignored - obligation of cert. dealers would be to check that a) owners is who he claims to be (e.g. by checking relevant documents) and b) owner actually is the owner of a given system or domain.

    Nope, complete and utter nonsense. It has nothing inherently to do with "legal entities". Straight from the X.509 specification:

    Users of a public key require confidence that the associated private
    key is owned by the correct remote subject (person or system) with
    which an encryption or digital signature mechanism will be used.

    You're just making stuff up here to suit your views. In reality, the exact means of verification is left up to the implementer, as far as the X.509 specification is concerned; separate guidelines have come to exist over the years (from eg. the CA/Browser Forum), but these were never part of the original design nor intentions.

    Except for EVs (and I wouldn't bet much on that either) certs - in the best of cases - show that someone was/is in control of the domain and/or server at some point in time (or at least succeeded to convince some cert. dealer or LE of it).

    Yes, and that's the point. The intention is to verify that there is no MITM intercepting the connection and re-encrypting before forwarding traffic to the destination (while pretending to be the destination), for which DV during issuance is sufficient.

    It means that an MITM cannot obtain a certificate that validates for the hostname whose traffic they're trying to intercept, because they do not have the necessary access to the domain to validate their issuance request.

    bsdguy said: The two caveats with LE are: a) they are all but worthless and even worse than cheap dealer certs (who at least have some kind of payment info, whose worth, of course, often is low). Both dealer DV certs and LE certs are basically but a formality (and usually also obtained for that reason ("to somehow have ssl stuff working without warnings")).

    Already covered this; the "formality" is sufficient for the purposes of preventing MITM.

    bsdguy said: b) with LE you basically open a backdoor for them on your system.

    And what "backdoor" would that be, exactly?

    bsdguy said: Important side note: There is reason to believe that LE is in bed with the cert and browser mafia. They have serious money, support, and big names behind them and would certainly have the clout to do some real repair of the utterly cert. clusterfuck - but they didn't. They did not make the wen more secure but they chose to keep the rotten system completely unchanged and to just turn one screw, namely price.

    And how exactly would they "repair" it? You seem to be grossly underestimating the complexity of key exchange and verification.

    bsdguy said: It is noteworthy that the power behind LE could as well have fought for acceptance of self signed certificates (which are absolutely no less trustworthy than LE certs) but chose not to.

    What are you smoking? A self-signed certificate is absolutely less trustworthy than an LE-signed certificate, because now anybody can trivially MITM a connection and present their own certificate, and your browser isn't going to know the difference. This is precisely the scenario that domain validation prevents.

    bsdguy said: What would be desirable? One example would be to link certs to the one place that actually can make a statement about domain ownership, namely the registries. All that would be needed were a single new field in the domain record, namely e.g. the domains public key.

    You do realize that certificates are issued on a per-hostname basis, not a per-domain basis? There is no such thing as "the domain's public key", and this would introduce a host of other potential issues (such as increased centralization of issuance and revocation).

  • Brace yourself. Changing is coming. A good one. If you think that's bad , well, you're free to think anything.

  • Im happy now, having achieved the shitstorm to the fullest effect, i'm off to sleep now.
    I'll have something fun to read during my morning coffee tomorrow.

  • SplitIceSplitIce Member, Provider

    I fail to see how this is anything but a step in the right direction. SSL != Trust. This is something that due to LE is truer than ever, it will take time but people (and companies) will adapt.

    Thanked by 2sibaper nulldev
  • jarjar Provider

    @SplitIce said:
    I fail to see how this is anything but a step in the right direction. SSL != Trust. This is something that due to LE is truer than ever, it will take time but people (and companies) will adapt.

    Plus the real idiots out there you can't save with or without SSL, or even with physical barriers. Stupidity is an unstoppable force.

    Thanked by 2Falzo nulldev
  • YuraYura Member
    edited July 2017

    @jarland said:

    @SplitIce said:
    I fail to see how this is anything but a step in the right direction. SSL != Trust. This is something that due to LE is truer than ever, it will take time but people (and companies) will adapt.

    Plus the real idiots out there you can't save with or without SSL, or even with physical barriers. Stupidity is an unstoppable force.

    If Einstein and DO Support Lead say so, it must be true.

    Gosh, it makes me shiver to imagine what empirical evidence you have on that...

    Thanked by 1Falzo
  • jarjar Provider
    edited July 2017

    Yura said: Gosh, it makes me shiver to imagine what empirical evidence you have on that...

    When I was 16 my first job was doing tech support for AOL over the phone. Most common question:

    "It says click OK, what do I do?"

    Power cable not plugged in was also a fairly common reason for the complaint "I can't connect to AOL."

  • SplitIceSplitIce Member, Provider
    edited July 2017

    Sir, the problem is that your keyboard is not getting enough power. You could get a new keyboard... but that's just a con, there is this neat trick. You see that big black cable coming from the wall, cut it. B-ZAP.

  • joepie91joepie91 Member, Provider

    @jarland said:

    @SplitIce said:
    I fail to see how this is anything but a step in the right direction. SSL != Trust. This is something that due to LE is truer than ever, it will take time but people (and companies) will adapt.

    Plus the real idiots out there you can't save with or without SSL, or even with physical barriers. Stupidity is an unstoppable force.

    The point of TLS (not "SSL") isn't to "save people", it's to make attacks more expensive. And that it does.

  • good!!!!

    Thanked by 1Aidan
  • jarjar Provider

    @SplitIce said:
    Sir, the problem is that your keyboard is not getting enough power. You could get a new keyboard... but that's just a con, there is this neat trick. You see that big black cable coming from the wall, cut it. B-ZAP.

    I kid you not, this happened:

    Me: I need you to click on your start menu
    Him: I don't see it
    Me: Should be in the bottom left corner of your desktop
    Him: Is that on my desk?
    Me: No. Here try this. On your keyboard, hold control and press escape.
    Him: Is that in my start menu?
    Me: No, your keyboard.
    Him: I don't see it.
    Me: It should be on your actual desk, next to your mouse. The thing you type on.
    Him: I don't see it.
    Me: I need you to call Dell and let them know that you can't find your keyboard. As soon as they help you locate it, give me a call back and we'll get this fixed up for you.
    Him: Ok, thanks.

  • bsdguybsdguy Member

    @joepie91 said:
    Oh man, so much bullshit in that post, where to begin...

    Lovely. And I have to commend you for the realistic introduction and marking of your post.

    bsdguy said: ssl ... much of it is badly designed and badly implemented

    • Heartbleed: This was a memory-related implementation bug in OpenSSL.

    I hope the visual hints can help you to understand.

    @joepie91 said:

    • Divergent implementations being detectable: Yes, this is likely true, and is true for just about every piece of software. That in and of itself is not a problem.

    That's the problem with people who think that having the "cryto.net" domain (note the missing 'p' in the poor mans version of the cool domain) somehow equates to actual crypto expertise.

    I'll help you again: My point was not about bit comparing different implementations but about comparing important cryptographic properties, which btw are i.a. to do with different lousy random generation. And to know which library was used in some software is an important giveaway, particularly as some implementations have known weaknesses.

    (EDIT: I only just realized you mentioned SSH there. SSH doesn't even use SSL, what are you going on about?)

    Look into the Makefile. SSH does use ssl. You just didn't get it because you missed the fact that (whatever)ssl provides two libraries, namely libssl and libcrypto and looking just for libssl you erred once more.

    bsdguy said: certificates are about stating that a given system, typ. a server or a domain, is "certified" by some third party to belong to a certain legal entity (person, company, ...). [...] The other and very important part is attribution and traceability, i.e. to establish a clear link between a domain or system and an "owning" legal entity as well as being sure about the legal entity.

    Nope, complete and utter nonsense. It has nothing inherently to do with "legal entities". Straight from the X.509 specification:

    Users of a public key require confidence that the associated private
    key is owned by the correct remote subject (person or system) with
    which an encryption or digital signature mechanism will be used.

    And how is that confidence gained? Usually by having a third party, i.e. a CA, signing ones public key.

    Yes, and that's the point. The intention is to verify that there is no MITM intercepting the connection and re-encrypting before forwarding traffic to the destination (while pretending to be the destination), for which DV during issuance is sufficient.

    It means that an MITM cannot obtain a certificate that validates for the hostname whose traffic they're trying to intercept, because they do not have the necessary access to the domain to validate their issuance request.

    You are so ignorant and clueless it really hurts.

    How about the bloody reality that plenty MITM attacks have been successfully performed?
    And there I'm generously leaving aside that due to the clusterfuck design and implementations utterly faked "certificates" have been successfully used, too. To name just one rather prominent example (in security circles. For you it seems to be new): Quite many programs (like e.g. browsers) have accepted for quite a long time arbitrarily made up certificates due to a classical '\0' C fuckup. So someone having a domain "evil-guy.com" got himself a valid certificate for "victim.com\0.evil-guy.com" which then was accepted as valid for "victim.com" because the certs didn't care and checked from last-to-first char and just saw "[whatever].evil-guy.com" which looked OK for them while the client side software just saw "victim.com" because using C string parsing that's what the program saw.

    bsdguy said: They [LE] have serious money, support, and big names behind them and would certainly have the clout to do some real repair of the utterly cert. clusterfuck - but they didn't. They did not make the wen more secure but they chose to keep the rotten system completely unchanged and to just turn one screw, namely price.

    And how exactly would they "repair" it? You seem to be grossly underestimating the complexity of key exchange and verification.

    That's actually double stupid from you. For one I did provide a hint and moreover, oh well, how do they do the switch from, say, tls 1.2 to 1.3? Well, exactly in the same way they could do other changes ("repairs"), too. Btw: pretty every ssl/tls version also was in part a repair of its predecessor version.

    What are you smoking? A self-signed certificate is absolutely less trustworthy than an LE-signed certificate, because now anybody can trivially MITM a connection and present their own certificate, and your browser isn't going to know the difference. This is precisely the scenario that domain validation prevents.

    LE requires one to have sufficient control over a system to run one of the "get me an LE cert" toys. Quite comparable to what's needed to install a self-signed cert.
    And again: an LE cert provides nothing but "someone on that system requested a cert from that system".

    So, all in all you are a guy who doesn't even master (let alone bringing up the interest) to do a ldd on ssh and on his systems [whatever]ssl library and who knows pretty much nothing about crypto (let alone having implemented some) and who knows not even about some better known successful attacks on ssl - but has a big mouth.

  • joepie91joepie91 Member, Provider

    bsdguy said: I hope the visual hints can help you to understand.

    You apparently need a visual hint as well:

    bsdguy said: much of it is badly designed and badly implemented

    Precisely zero of your points had anything to do with the design of "SSL". Heartbleed was an implementation bug in one specific implementation of TLS that is known to be of generally poor quality. None of this reflects on SSL/TLS as a protocol in any way, which was what your original claim was about. Perhaps you don't know the difference between SSL and OpenSSL?

    bsdguy said: That's the problem with people who think that having the "cryto.net" domain (note the missing 'p' in the poor mans version of the cool domain) somehow equates to actual crypto expertise.

    I'll entertain your personal attack for a moment: my domain name has nothing to do with "crypto" whatsoever. Swing and a miss.

    bsdguy said: I'll help you again: My point was not about bit comparing different implementations but about comparing important cryptographic properties, which btw are i.a. to do with different lousy random generation.

    Except you were talking about a specific obscure random number generator that was rarely used in real-world deployments and had nothing specifically to do with SSL/TLS, yet you presented it as if it were somehow an SSL issue.

    SSL/TLS are generic transport encryption protocols, with a wide variety of supported cryptographic primitives. An issue with a specific primitive or random source does not reflect on the protocol built around it.

    bsdguy said: Look into the Makefile. SSH does use ssl. You just didn't get it because you missed the fact that (whatever)ssl provides two libraries, namely libssl and libcrypto and looking just for libssl you erred once more.

    Again: you do not seem to understand the difference between "SSL" and "OpenSSL". One is a protocol, the other is a piece of software. The two are not inherently related. The libcrypto you're referring to is maintained by the OpenSSL project, but has nothing to do with the SSL protocol whatsoever.

    If you do not understand this very simple distinction, then there's really no further discussion to be had here. Treating two things as being the same thing just because they share a number of letters in their name is not a useful footing to have a conversation on.

    bsdguy said: And how is that confidence gained? Usually by having a third party, i.e. a CA, signing ones public key.

    Yes? That is what I'm talking about. What is your point here, exactly?

    bsdguy said: How about the bloody reality that plenty MITM attacks have been successfully performed? And there I'm generously leaving aside that due to the clusterfuck design and implementations utterly faked "certificates" have been successfully used, too. To name just one rather prominent example (in security circles. For you it seems to be new): Quite many programs (like e.g. browsers) have accepted for quite a long time arbitrarily made up certificates due to a classical '\0' C fuckup. So someone having a domain "evil-guy.com" got himself a valid certificate for "victim.com\0.evil-guy.com" which then was accepted as valid for "victim.com" because the certs didn't care and checked from last-to-first char and just saw "[whatever].evil-guy.com" which looked OK for them while the client side software just saw "victim.com" because using C string parsing that's what the program saw.

    You should perhaps be trying less hard to sound authorative, and take a step back to actually understand the topics you're talking about.

    Once again, a string termination bug is a bug in a specific implementation, not in SSL/TLS as a protocol, nor in the CA model. This has fuck all to do with what the discussion is about. Yes, if you fuck up the implementation of a security measure, then the security measure does not work as intended - why are you presenting this as if it's some sort of groundbreaking discovery?

    The "bloody reality", as you seem intent on putting it, is that domain validation is an effective measure to significantly reduce the amount of successful MITM attacks, leaving only the cases of 1) implementation error, 2) buggy local TLS proxies, and 3) occasional CA fuckup.

    Is it undesirable that MITM attacks can still occur in those edge cases? Sure, but that doesn't mean that domain validation is not valuable; if it stops even 95% of attacks (and it likely stops many, many more than that), then that is 95% more than not doing domain validation. No amount of EV is going to improve on that rate, either - after all, an EV certificate is not any less defeated by an implementation bug, nor a CA screwing up.

    And guess what? Protocols that aren't SSL/TLS aren't going to help you there either because, again, there's an implementation bug. The MITM prevention rate is not going to get any higher than with SSL/TLS. So why do you keep presenting this as some sort of SSL/TLS issue, when in reality it's a generic issue with buggy software and human error that would occur under any circumstances?

    In the end, security isn't about making things bulletproof. It's about making attacks expensive and unlikely enough to make them not worth it. While the CA model is by no means perfect, it is still doing a very good job at that in almost every scenario. Throwing it out will make things worse, not better.

    bsdguy said: That's actually double stupid from you. For one I did provide a hint and moreover, oh well, how do they do the switch from, say, tls 1.2 to 1.3? Well, exactly in the same way they could do other changes ("repairs"), too. Btw: pretty every ssl/tls version also was in part a repair of its predecessor version.

    I'm not asking you about how to do the migration. I'm asking you what you'd propose to migrate to. What implementation do you believe would work better than the CA model that we have currently?

    bsdguy said: LE requires one to have sufficient control over a system to run one of the "get me an LE cert" toys. Quite comparable to what's needed to install a self-signed cert. And again: an LE cert provides nothing but "someone on that system requested a cert from that system".

    I'm increasingly convinced that you don't even understand the basics of how TLS works. A self-signed certificate does not require that you have access to the hostname you are creating it for, whereas a Let's Encrypt certificate does. The two are not comparable, and blindly accepting self-signed certificates would completely defeat TLS against active attackers, because anybody can generate a certificate on your behalf and intercept any traffic to you.


    You're a pretty good bullshit artist, I'll give you that. You seem rather skilled at pasting together bits of technical detail that are correct in isolation, and turn it into a narrative that - despite being completely wrong - sounds credible to somebody who doesn't understand how the technology works. I've been suspecting this for a while, and this thread seems to confirm it.

    A summary:

    • SSL/TLS (the protocols) and OpenSSL are not the same thing. They're not inherently related either. OpenSSL is simply one implementation of many.
    • OpenSSL implementation bugs are not protocol bugs. They do not affect TLS as a protocol.
    • SSL/TLS are not cryptographic primitives. They're network protocols. Cryptographical design failures in primitives supported by SSL/TLS are not bugs in SSL/TLS.
    • Protecting from 95% of attacks is better than protecting from 0% of attacks.
    • You still haven't told me why you think RSA is broken.

    You never actually addressed my question about the supposed "backdoor" either, by the way. I'm going to guess that you thought you could just let that claim sneak away unnoticed when challenged on it.

  • bsdguybsdguy Member

    @joepie91

    You should see me sitting here with a big grin. I knew that you would save me the work by doing what could be called discursive sepuku.

    Try again once you know how to use ldd and having ported and implemented an assortment of crypto and security software in both C and Ada (in my case; ML or F star are acceptable too).

    And btw: Good luck using standards and protocols on paper. In the real world we have to use implementations, you know, the stuff that you talk about and that people like myself actually work on, Mr. cryto.net\0blabla.org . ;)

  • joepie91joepie91 Member, Provider

    @bsdguy said:
    @joepie91

    You should see me sitting here with a big grin. I knew that you would save me the work by doing what could be called discursive sepuku.

    Try again once you know how to use ldd and having ported and implemented an assortment of crypto and security software in both C and Ada (in my case; ML or F star are acceptable too).

    And btw: Good luck using standards and protocols on paper. In the real world we have to use implementations, you know, the stuff that you talk about and that people like myself actually work on, Mr. cryto.net\0blabla.org . ;)

    No amount of bragging or namedropping is going to make your claims any less wrong.

  • bsdguybsdguy Member

    @joepie91 said:

    No amount of standards quoting and general knowledge faking is making ssl/tls any safer nor it making the fact go away that you did not even know the simple and easy to find out and to verify fact that ssh does use ssl.

  • joepie91joepie91 Member, Provider
    edited July 2017

    @bsdguy said:

    @joepie91 said:

    No amount of standards quoting and general knowledge faking is making ssl/tls any safer nor it making the fact go away that you did not even know the simple and easy to find out and to verify fact that ssh does use ssl.

    Once again: no, SSH does not "use SSL". OpenSSH uses libcrypto, which is a library from the OpenSSL project. Those are two completely different things. I don't know why you're finding it so hard to understand that "SSL" and "OpenSSL" are not the same thing.

    To re-emphasize: OpenSSH uses libcrypto. libcrypto does not implement the SSL protocol. Therefore, neither OpenSSH (the software) nor SSH (the protocol) use "SSL".

    Thanked by 2maverickp nulldev
  • bsdguybsdguy Member
    edited July 2017

    @joepie91

    libcrypto implements pretty much all of the crypto in []ssl. Moreover libcrypto contains all that is needed for public key exchange and other vital elements for ssl/tls. One could even say that []ssl is but a library wrapper around libcrypto offering some ssl functionality ssh (and many others) doesn't need but web related stuff needs.

    While you continue to dabble in protocols theory and (rather uninformed) ssl/tls evangelization, we do have real and serious problems in the field of IT security.

    To offer just one example (that happens to currently be in the news) -> https://www.nytimes.com/2017/07/06/technology/nuclear-plant-hack-report.html

    That problem class is related to both crypto (largely being absent or primitive) and to scada being a security nightmare.

    Another and deeper problem class is that we have to choose between either algorithms that are well established and understood but based on only 2 security reductions, namely rsa and ecc, or rather new algorithms that unlike the current ones are supposed to be post-quantum secure but are not yet well enough understood, let alone established (e.g. lattice or hash based crypto).
    And as if that weren't frightening enough, vast bodies of security related software (like servers and browsers) are riddled with quite questionable implementations and lots of errors yet to be found, some of them fatal.

    You see, I shit on the protocols and standards you love to wave around. Simple reason: they are worthless unless they are a) formally verified and b) properly specified, modelled, and implemented in a verifiable way.
    Guess what: tls 1.3 is the first tls version that has at least been properly specified. Without being formally specified and modelled a protocol is but toilet paper. Besides some (laudable) security fanatics who work on implementing tls in F star (which, however, is practically quite useless) tls is implemented once more in C, a language that can not possibly be used to create verifiable code.

    So forgive me if my patience with Mr. "crypto is my hobby" is rather limited. If you really care more than a rats ass about security you should actually be happy about people like me. But, you see, patiently discussing with you and ever so slooooowly moving you towards the lights might be a laudable goal; unfortunately, however, there are medical systems, weapon systems, air control systems, nuclear systems and the like waiting to be taken out of the danger zone.

  • Cloudflare has issued Free Wildcard SSL For Sometimes now. Why people raging when LE do it.

  • bapbap Member

    @raindog308 said:
    I don't feel safe!

    image

    >

    You should starts using condoms...
    or pills..

    Wildcard certificates will be offered free of charge via our upcoming ACME v2 API endpoint.

    I love free stuff!

  • williewillie Member

    bsdguy said:

    So forgive me if my patience with Mr. "crypto is my hobby"

    You are not coming across as very knowledgeable yourself. Buzzword bingo only gets you so far.

    Thanked by 1raindog308
  • yokowasis said: Cloudflare has issued Free Wildcard SSL For Sometimes now. Why people raging when LE do it.

    any source?

  • bsdguybsdguy Member

    @willie said:

    bsdguy said:

    So forgive me if my patience with Mr. "crypto is my hobby"

    You are not coming across as very knowledgeable yourself. Buzzword bingo only gets you so far.

    I don't care how I come across. That's utterly unimportant. Important is what one knows and, in this case, what actual experience one has based on actually written code, formal specifications (e.g. tla+), and formal verification (both for code and for crypto protocols).

    Just for the fun of it

    param attacker = active . (* Assume worst Dolev-Yao attacker *)
    
    free c .
    private free GID  .     
    
    fun hash/2 .(* ( GID : bitstring, bitstring) :  RndChl: bitstring - return bitstring *)
    fun senc/2 . (* (command, key) : bitstring *)
    reduc sdec(senc(x,y),y) = x.
    
    query attacker : GID . 
    query ev:ClientChallengeResponse(RC) ==> ev:ServerChallenge(RC) .
    (* implicitely but necessarily proves the client is authorized *)
    query attacker : cmd.
    
    let ProcClient =
        new cmd;    
        in(c, RC);  
        event ServerChallenge(RC) ;
        out(c, (hash(RC, GID), senc(cmd, GID)));
        event ClientChallengeResponse(RC) .
    
    let ProcServer =
        new RndChl; (* bitstring ;  128 bit random challenge *)
        out(c, RndChl);
        in(c, (ChlResp, eCmd)); 
        if hash(RndChl, GID) = ChlResp then
            event CmdRecvd(sdec(eCmd, GID))
        else 0.
    
  • WilliamWilliam Member, Provider
    edited July 2017

    bsdguy said: I hope the visual hints can help you to understand.

    You are aware that you do not have to use OpenSSL, right? Microsoft IIS generates certs without openssl entirely, as do a LOT of hardware appliances.

    None of these had any heartbleed issues.

    bsdguy said: How about the bloody reality that plenty MITM attacks have been successfully performed?

    Only if the attacker had control of a valid CA in the users system. No CA has ever been re-generated from only public available data and with current computing capacity this is aside of a nearly impossible random hit impossible.

    bsdguy said: LE requires one to have sufficient control over a system to run one of the "get me an LE cert" toys

    No, it does not - you can totally run the cert creation on another system and just upload the file on the webhost. Zero issue.


    I do not claim to have crypto idea overall and my math knowledge (or rather usability) is on the autism spectrum, but these points are even clear to me...

  • bsdguybsdguy Member
    edited July 2017

    @William said:
    You are aware that you do not have to use OpenSSL, right? Microsoft IIS generates certs without openssl entirely, as do a LOT of hardware appliances.

    None of these had any heartbleed issues.

    Absolutely. And while, yes, openssl is a particularly bloody one, all ssl implementations had problems at some point in time.

    Moreover and more importantly: heartbleed is but one, albeit particularly nasty and well know problem; I mentioned it as an example.

    bsdguy said: How about the bloody reality that plenty MITM attacks have been successfully performed?

    Only if the attacker had control of a valid CA in the users system. No CA has ever been re-generated from only public available data and with current computing capacity this is aside of a nearly impossible random hit impossible.

    Wrong. See my example above with victim.com\0evil-guy.com. That is not theory, that problem existed for quite some years.

    bsdguy said: LE requires one to have sufficient control over a system to run one of the "get me an LE cert" toys

    No, it does not - you can totally run the cert creation on another system and just upload the file on the webhost. Zero issue.

    If that is true than it's even worse in that LE does not even give that minimal guarantee.

    You see, there are profound problem classes on multiple levels. I named an example above: A standard has a useful function but it's worth nothing if it isn't properly modelled and verified. And that's no my private exotic view; that the (meanwhile and finally) well understood state of art.

    Another example: A standard doesn't care about implementation, e.g. about how a given programming language works. This also was a concrete and long existing problem because there are subtle algorithmic differences. One implementation might (as has happened) scan a fqdn backwards and that makes sense considering how the domain name system works. Another implementation, however, might go the usual C route, namely to scan strings as char arrays and forward until \0. Exactly that was the attack vector for MITM attacks, because the CA software thought it had issued a cert for evil-guy.com while the client software saw a cert for victim.com.

    C is a major culprit anyway, i.a. because while being very widely used it is ambiguous and can not possibly be formally verified; the best one can do is to verify what a given compiler takes C to mean. And even then it's difficult.

    It is for those reasons that two things happened recently or are currently happening: a) tls 1.3 has a formal spec. (it's idiotic anyway but at least it's "properly idiotic" g) and b) tls is implemented in F star (an exotic language that allows to formally statically verify code).
    The *vast
    majority of actually used code, however, is based on not properly specified, let alone modelled standards and on quite poor C code.

    It's simply nonsensical and untenable to call ssl or any common implementation of it "safe" or "secure".

    You want such a statement to mean something, right? You want that when XYZ is called secure then it actually is secure. But how can we call XYZ secure when its standard is not properly designed and verified and when its implementation has but some unit tests if that. What does "secure" mean then?

  • @sibaper said:

    yokowasis said: Cloudflare has issued Free Wildcard SSL For Sometimes now. Why people raging when LE do it.

    any source?

    No Source, Take my word for it. Moreover it expire years from now.

  • SplitIceSplitIce Member, Provider

    @yokowasis only furthering the point SSL != Trust. But if that's to be beleived it sounds like extremely bad practice. What happens when the domain changes hands some time in the next 15 years?

    Hmm... perhaps SSL certificates should be tied to domain expiration...

  • WilliamWilliam Member, Provider

    bsdguy said: If that is true than it's even worse in that LE does not even give that minimal guarantee.

    Why? You just upload the file with the hash to the webserver which it calls then, why would there be ANY need to generate it there? This in no way degrades any security in any way.

    This is literally the same as a reverse proxy, obviously LE works behind a reverse proxy as it just passes the req for the verification file to the backend server 1:1....

    You can also use the same file based verification on MANY commercial CAs, this is not a LE unique feature and they were not the first with it either.

    bsdguy said: Exactly that was the attack vector for MITM attacks, because the CA software thought it had issued a cert for evil-guy.com while the client software saw a cert for victim.com.

    This is a CA code bug, not a security issue of TLS/SSL.

    bsdguy said: It's simply nonsensical and untenable to call ssl or any common implementation of it "safe" or "secure".

    You did in no way prove that the actual crypto is not secure, you only show things that depend on CA software used and validation issues. Severity wise this is below heartbleed entirely.

    Thanked by 1maverickp
This discussion has been closed.