Howdy, Stranger!

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

Subscribe to our newsletter

Advertise on LowEndTalk.com

Latest LowEndBox Offers

    Let's Encrypt Wildcard Certificates Coming in January 2018
    New on LowEndTalk? Please read our 'Community Rules' by clicking on it in the right menu!

    Let's Encrypt Wildcard Certificates Coming in January 2018

    According to the Let's Encrypt blog free wildcard certs are on their way.

    They're also looking for donations if you're able and willing.

    «1

    Comments

    • wow thats a big news :)

    • WSSWSS Member

      As fast and loose as LE already is, enabling wildcards is going to mean more complete shit with SSL certificates- and I'm talking about malware sites with pretty green checkboxes at the upper left.

      I won't be back until @bsdguy is released.

    • FranciscoFrancisco Top Provider

      @WSS said:
      As fast and loose as LE already is, enabling wildcards is going to mean more complete shit with SSL certificates- and I'm talking about malware sites with pretty green checkboxes at the upper left.

      Ah, the $4/year SSL gate to stop the malware people.

      Francisco

      BuyVM - Dedicated KVM Slices / Anycast Support! / Stallion Control Panel / Windows 2008, 2012, & 2016! / Unmetered Bandwidth!
      BuyShared - Shared & Reseller Hosting / cPanel + Softaculous + CloudLinux / Pure SSD! / Free Dedicated IP Address
    • @WSS said:
      As fast and loose as LE already is, enabling wildcards is going to mean more complete shit with SSL certificates- and I'm talking about malware sites with pretty green checkboxes at the upper left.

      That's the browser makers fault. LE will just ensure that the channel over which the virus is being sent your way cannot be eavesdropped on.

      I like my uptime down low and my servers all hacked. Can see me droppin' twenty-fours with a router in the rack.
      Ya like ya Switch-Ports hot and ya servers all hacked. If ya pings real high and ya networks pitch black.

    • TomTom Member
      edited July 2017

      Just in time as @Fidde is starting to have problems with ASSL :-)

      Thanked by 1Fidde
    • FranciscoFrancisco Top Provider

      and with that, the SSL cartels are laid to rest.

      Francisco

      Thanked by 4WSS leonari dwtbf Makenai
      BuyVM - Dedicated KVM Slices / Anycast Support! / Stallion Control Panel / Windows 2008, 2012, & 2016! / Unmetered Bandwidth!
      BuyShared - Shared & Reseller Hosting / cPanel + Softaculous + CloudLinux / Pure SSD! / Free Dedicated IP Address
    • joepie91joepie91 Member, Provider
      edited July 2017

      Somebody on IRC pointed out that this may cause dangerous behaviour from users. Specifically: Wildcard certificates should NOT be used for "easy subdomains". By sharing the same certificate between multiple systems, you're compromising the security of your TLS setup.

      An example of a valid usecase for wildcart certificates is "multi-tenant website, hosted from the same server cluster for everybody, and every user gets their own subdomain". In this case, you're protecting the same system, even if it uses a number of different hostnames depending on whose profile you're viewing.

      An example of an invalid usecase for wildcard certificates is "oh, now I don't need separate certificates for mail. and www. and irc. anymore, I can just use the same certificate everywhere" -- do not do this, just use a separate certificate for each service as before.

      WSS said: As fast and loose as LE already is, enabling wildcards is going to mean more complete shit with SSL certificates- and I'm talking about malware sites with pretty green checkboxes at the upper left.

      TLS certificates were never meant to provide any assurance about the safety of a website itself. This is 100% snakeoil marketing spread by TLS certificate sellers. It's a non-argument.


      EDIT: To be clear, this is great news, and I've long been waiting for LE to cover the remaining 1% of usecases that couldn't currently be implemented due to certificate request rate limits. I just hope it isn't going to be abused by the 99% that don't need it.

    • stefemanstefeman Member
      edited July 2017

      Theres already fake banks with green SSL bars/text/lock thanks to Let's Encrypt.

      Wildcards won't change anything in that sense.. People are thaught that SSL/HTTPS = Security/Trust. This is being exploited by malware sites now.

      I think the SSL cartel is horrendous, but we already had solution for it like namecheap/ssls.com. The fact there remains some payment gateway requirement and manual job/traceable stuff is what kept majority of the fraud sites from having SSL in the first place.

      It has to cost money and it has to be tracebale to some extend and it also must not be too easy to mass produce, or there will be abuse and fraud.

      Personally my own opinion is that Let's Encrypt made the internet much more risky for a normal average household user. It was never needed.. We had cheap <10 USD SSLs before.

      Thanked by 1WSS
    • WSSWSS Member

      I just thought I'd get it out of the way before @bsdguy came here and started pissing all over LE. I didn't actually expect a huge derail about how much it is a non-op issue. Yes, it will affect some idiots, and yes, you can still buy cheap SSL certificates and see them on malware sites.

      I'll use sarcasm tags next time.

      I don't really like the idea of LE wildcards because, as mentioned already, it sets a bad precedent. Then again, I still don't really like SNI, either, but at least it lets you setup multiple certificates on an IP, rather than just one wildcard certificate across the domain.

      I won't be back until @bsdguy is released.

    • rm_rm_ Member
      edited July 2017

      joepie91 said: I just hope it isn't going to be abused by the 99% that don't need it.

      What is there to abuse? It's not any more difficult to issue a wildcard than a regular cert. In fact even easier on them, since you're not bombarding their server with requests to validate all 5-10-15 of your subdomains, and instead just get a single cert for all of those.

    • That is good news.
      I don't get what your problem with LE is, they are very good for the internet. It is not their fault that you guys are stupid. There is still EV.

    • WilliamWilliam Member, Provider

      stefeman said: Theres already fake banks with green SSL bars/text/lock thanks to Let's Encrypt.

      No, there are no phishing sites with valid EV certs unless the site is entire hijacked.

      stefeman said: I think the SSL cartel is horrendous, but we already had solution for it like namecheap/ssls.com

      No, they still make money out of something that does not cost them anything.

      stefeman said: The fact there remains some payment gateway requirement

      Bitcoin is anonymous. Anonymous CCs are, well, anonymous. Prepaid CCs are issued to anyone with a valid looking ID.

      stefeman said: and manual job/traceable stuff is what kept majority of the fraud sites from having SSL in the first place.

      No CA verifies SSLs manually unless you get flagged like i with certain domains (especially .IR).

      A lot of absolutely not trustworthy organizations have widespread root CAs as well - like Turktrust, a bunch of Chinese gov related companies, some universities...

      stefeman said: Personally my own opinion is that Let's Encrypt made the internet much more risky for a normal average household user

      It's good that you are wrong then, because it did not. In no way. At all.

      If anything the higher SSL adoption, especially by the free implementations in nearly all control panels, did higher the overall security.

      You are somehow under the illusion that the A record verification is less secure than DNS or email which is absolutely not true.

      WSS said: but at least it lets you setup multiple certificates on an IP, rather than just one wildcard certificate across the domain.

      SNI works with wildcard also.

    • joepie91joepie91 Member, Provider
      edited July 2017

      stefeman said: It has to cost money and it has to be tracebale to some extend and it also must not be too easy to mass produce, or there will be abuse and fraud.

      Personally my own opinion is that Let's Encrypt made the internet much more risky for a normal average household user. It was never needed.. We had cheap <10 USD SSLs before.

      I don't think you understand what TLS certificates are for. They exist to prove control of a domain, so as to verify the legitimacy of a presented keypair for transport encryption. That's the only purpose. Everything beyond that is fluff invented out of thin air by (commercial) third parties.

      Given that purpose, it is absolutely not in the slighest desirable that certificates cost anything at all. Neither traceability or cost are useful properties for a TLS certificate - it's simply out of scope for what certificates are meant to do, and actively harms adoption.

      Complaining that TLS certificates are handed out to untrustworthy sites, is like complaining that your blender doesn't catch burglars - it was never its purpose in the first place, and is out of scope. If you want to catch burglars, there are separate solutions for that, and the same applies for preventing access to harmful sites (eg. Safe Browsing).

      rm_ said: What is there to abuse? It's not any more difficult to issue a wildcard than a regular cert. In fact even easier on them, since you're not bombarding their server with requests to validate all 5-10-15 of your subdomains, and instead just get a single cert for all of those.

      I don't mean "abuse" in the "affect other parties negatively" sense, rather in the sense of using things for inappropriate purposes. It's very likely that people will interpret this as "oh now I only need one certificate for all my services", which will actively harm the security of their services without them realizing it.

      Wildcard certificates aren't meant to be used for multiple services, but if somebody doesn't understand the mechanics behind the different kinds of certificates and how their exact level of protection varies, it will certainly look convenient.

      EDIT: To clarify: by using a wildcard certificate for multiple independent services, you create a single point of failure where a single leaked certificate from any of your servers can be used to impersonate any of your other services, regardless of whether the attacker has access to the server that they run on, completely breaking transport encryption for everything.

      That's why you don't want to use wildcard certificates for multiple services. They apply to everything under your domain.

      Thanked by 1Aidan
    • stefemanstefeman Member
      edited July 2017

      I know what they are for.. DV Certificates are for exactly as you described, too bad majority of the internet users do not know this.. When their bank and news tells them to just check for https and green lock to determine that the website is not fake, disregarding the checking of the actual domain name in question, it's just making it easier/faster for fraudsters to make use of this information in order to gain trust of the users.

      While I agree, this belief needs to change, this does not change the current situation right now, therefore for an average internet user that visists 3-10 websites a month, it's much more risky just because there are fake bank sites with LE certificate posing as legit ones via emails and ads.

      DV certificates do not say anything about trustworthiness, but try asking yourself, how many people does actually even know that there are many different SSL types rather than one which to trust? Anyone that would use this forum or related expert sites obviously knows of these stuff, but we're less than 0.1% of the userbase.

      Thanked by 1ranpha
    • joepie91joepie91 Member, Provider

      @stefeman said:
      I know what they are for.. DV Certificates are for exactly as you described, too bad majority of the internet users do not know this.. When their bank and news tells them to just check for https and green lock to determine that the website is not fake, disregarding the checking of the actual domain name in question, it's just making it easier/faster for fraudsters to make use of this information in order to gain trust of the users.

      While I agree, this belief needs to change, this does not change the current situation right now, therefore for an average internet user that visists 3-10 websites a month, it's much more risky just because there are fake bank sites with LE certificate posing as legit ones via emails and ads.

      And that belief isn't going to change until people learn the hard way, and companies no longer have the option to spin myths about green locks meaning a site is safe. There's absolutely no fault on Let's Encrypt here, the fault lies entirely with those parties who have been spreading crap about green locks throughout the years.

      This situation was never going to change in any other way than by force.

    • stefemanstefeman Member
      edited July 2017

      @joepie91 said:

      @stefeman said:
      I know what they are for.. DV Certificates are for exactly as you described, too bad majority of the internet users do not know this.. When their bank and news tells them to just check for https and green lock to determine that the website is not fake, disregarding the checking of the actual domain name in question, it's just making it easier/faster for fraudsters to make use of this information in order to gain trust of the users.

      While I agree, this belief needs to change, this does not change the current situation right now, therefore for an average internet user that visists 3-10 websites a month, it's much more risky just because there are fake bank sites with LE certificate posing as legit ones via emails and ads.

      And that belief isn't going to change until people learn the hard way, and companies no longer have the option to spin myths about green locks meaning a site is safe. There's absolutely no fault on Let's Encrypt here, the fault lies entirely with those parties who have been spreading crap about green locks throughout the years.

      This situation was never going to change in any other way than by force.

      So rather than fix the problem first, let's just hand the weapons of destruction to the hands of terrorists hoping people get wiser? Sure, things are changing fast now, but what at cost?

      The overall increase of SSL was happening fast anyway due cheap certificates, LE just gave "trust" to everyone free for any usage including abusers that mass their fraud sites now easier than ever.

    • @stefeman said:
      Theres already fake banks with green SSL bars/text/lock thanks to Let's Encrypt.

      >

      Personally my own opinion is that Let's Encrypt made the internet much more risky for a normal average household user. It was never needed.. We had cheap <10 USD SSLs before.

      How would this make the web more risky? If you trust anything with a certificate on it sure, but that has nothing to do with SSL making things risky. That's just the ignorance of the average user.

      Speaking of the average user, I doubt they actually know what the 'green lock' is for and if they even notice it or actually look for it at all.

      I personally think LE is a great initiative and I can see this moving forward. We're all bickering about it but at the end of the day fact is that in a couple of years every website will have a certificate, either payed for or free.

    • stefemanstefeman Member
      edited July 2017

      @Saragoldfarb said:

      @stefeman said:
      Theres already fake banks with green SSL bars/text/lock thanks to Let's Encrypt.

      I personally think LE is a great initiative and I can see this moving forward. We're all bickering about it but at the end of the day fact is that in a couple of years every website will have a certificate, either payed for or free.

      I'm all for encrypted internet, but this is the wrong way in my opinion. It just sacrifices all dumb users for the sake of a fast change. If theyre gonna continue, at least make their abuse department faster.. it took them 2 weeks to revoke a cert to a fake Nordea banksite I reported.

    • raindog308raindog308 Moderator

      I don't feel safe!

      image

      For LET support, please visit the interim support desk.

    • WilliamWilliam Member, Provider

      stefeman said: So rather than fix the problem first, let's just hand the weapons of destruction to the hands of terrorists hoping people get wiser? Sure, things are changing fast now, but what at cost?

      To stay within your example - any terrorist can buy this weapons in no time.

    • stefemanstefeman Member
      edited July 2017

      @William said:

      stefeman said: So rather than fix the problem first, let's just hand the weapons of destruction to the hands of terrorists hoping people get wiser? Sure, things are changing fast now, but what at cost?

      To stay within your example - any terrorist can buy this weapons in no time.

      Why would they buy it when they can have it for free.. in mass quantities? They're over deciding whetever to buy or not.. they can just get one for free.. and very easily.. and this changes things as we see in explosiveness of fraud sites with LE certs.

      In fact they don't even have to worry about bad investments.. as we know, they cycle domains a lot due reports and user flagging. Buying SSL for all fraud domains would take more cash than they make in year, but with LE they'll have just that for all of their domains without any cost in time or money.

    • joepie91joepie91 Member, Provider

      stefeman said: So rather than fix the problem first,

      Then please tell me how you plan to "fix the problem" without forcing the hand of those causing it. People have been trying this for years without success, because it's too profitable to keep spreading misinformation.

      stefeman said: it took them 2 weeks to revoke a cert to a fake Nordea banksite I reported.

      They shouldn't even revoke that certificate.

    • stefemanstefeman Member
      edited July 2017

      I would fix the problem with media campaign and time and cheap certificates instead of free stuff to abuse, while majority of the people trust/relies on the technology.

      @joepie91 said:
      They shouldn't even revoke that certificate.

      So you are saying that it's okay to get a certificate for a phishing website intended to steal funds/personal information by borrowing the name of another entity/company? On top of that it was part of an email scam campaign attempted to gain access to victim's bank accounts.

      Not to say about the clear ToS Let's Encrypt has about taking down phising sites? Are you running such operation yourself then, or why are you saying that?

      How would you feel if I registered similar domain to your hosting company and got SSL for it and started targeting your users with your own template to make harm to your customers in your name? ofc none of them would be stupid enough to fall for it, but if you were in another industry area, you'd be fucked or at least annoyed for me using your name to scam people.

    • EdmondEdmond Member without signature

      It's a nice thing that they'll make LE wildcard friendly, thought they weren't going to do such thing and I'd just have to stick with a list of subdomains in my cert...

      They should make getting LE certificates a bit harder, like maybe your account needs to be at least two weeks old and requires text verification?

    • @stefeman said:

      @William said:

      stefeman said: So rather than fix the problem first, let's just hand the weapons of destruction to the hands of terrorists hoping people get wiser? Sure, things are changing fast now, but what at cost?

      To stay within your example - any terrorist can buy this weapons in no time.

      Why would they buy it when they can have it for free.. in mass quantities? They're over deciding whetever to buy or not.. they can just get one for free.. and very easily.. and this changes things as we see in explosiveness of fraud sites with LE certs.

      In fact they don't even have to worry about bad investments.. as we know, they cycle domains a lot due reports and user flagging. Buying SSL for all fraud domains would take more cash than they make in year, but with LE they'll have just that for all of their domains without any cost in time or money.

      They are not weapons. It's like saying "don't sell safes because people can hide drugs in them" or "don't encrypt data because the terrorists can use it transmit their secret c0des". Yes, you can hide drugs in safes, but there are other purposes for safes... Yes, you can transmit secret bombing plans over an encrypted line, but there are other reasons for data encryption.

      Yes, you can get an SSL cert for your fraud website, but people need certs for other things as well...

      As a high school student, I would rather not pay $100+ dollars for a wildcard cert when I need one... I just don't have that kind of money.

      Bored developer: https://nulldev.xyz/

    • joepie91joepie91 Member, Provider

      stefeman said: I would fix the problem with media campaign and time and cheap certificates instead of free stuff to abuse, while majority of the people trust/relies on the technology.

      Been tried, doesn't work.

      stefeman said: So you are saying that it's okay to get a certificate for a phishing website intended to steal funds/personal information by borrowing the name of another entity/company? On top of that it was part of an email scam campaign attempted to gain access to victim's bank accounts.

      Except you're not, from a TLS point of view. Again, a DV certificate only assures the client that the server they are talking to is controlled by the same person that also controls the domain. This has nothing to do with "another entity/company", and is therefore out of scope, and not a valid reason to revoke anything - the cert is not compromised nor was it incorrectly issued.

      Now if an EV certificate was issued incorrectly to an impersonator, or a DV certificate for the real bank's domain were issued, sure, that would be valid reasons for revocation. But in this case, a certificate for somephishingsite.com was issued to a server controlled by the same person who controls the somephishingsite.com domain, and therefore the certificate is valid and should not be revoked.

      What's on the site is irrelevant from a TLS perspective. The only purpose of TLS is to encrypt the connection and secure it from MITM attacks.

      stefeman said: Not to say about the clear ToS Let's Encrypt has about taking down phising sites? Are you running such operation yourself then, or why are you saying that?

      I'm saying that because I actually understand how TLS works and how it is designed, and because revoking certificates of phishing sites is a dangerous slippery slope with unclear legal definitions that very quickly turns into political issues. TLS certificates of controversial sites have been revoked in the past for ToS-related reasons.

      TLS should remain strictly a technical security measure providing transport encryption. It shouldn't become an umbrella for all kinds of political access control mechanisms. Therefore, any kind of revocation, for any reason other than "not issued in accordance with what TLS is designed for", is undesirable, regardless of the circumstances.

      And no, I do not run phishing sites. Even if I were ethically okay with it, I'd be a moron to do so, given how public I am about my identity.

    • stefemanstefeman Member
      edited July 2017

      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

      In the case of somesite.com and someesitee.com where both websites have different purpose and outlook with no relation to each other from either side, then ofc I would support for not revoking certificate from either site even if one requests so by finding out the other.

    • hzrhzr Member, Moderator
      edited July 2017

      stefeman said: So you are saying that it's okay to get a certificate for a phishing website intended to steal funds/personal information by borrowing the name of another entity/company? On top of that it was part of an email scam campaign attempted to gain access to victim's bank accounts.

      A domain is a domain, a DV validates that the requestor has appropriate access to that domain and nothing more. If someone owns paypallegit.xxx and requests a cert for it and can demonstrate proper control over the domain, it can and should be issued.

      If PayPal for example gets that domain seized/taken, then they can request a revocation as the new owner of the domain after completing a challenge-response demonstrating control.

      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

      When Nordea.fi gets Nordeaa.fi seized and take control of the domain, they can validate they own the domain and revoke certs. If it's from LE, revocation is automated after you demonstrate you control the domain it's issued for. Intention has zero matter, only access to the domain.

      Thanked by 1nulldev
    • WilliamWilliam Member, Provider

      stefeman said: would it not be justified to revoke that certificate

      No, the FI registry should disable the domain, as their legal obligation is. Assuming the hosting provider will not before them anyway.

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

      Without court order LE shouldn't take any action

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

      My favourite prime number is 42. - \forall cpu in {intel, amd, arm}: cpu->speed -= cpu->speed/100 x irandom(15, 30) | state := hacked

    • 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
      X4B - DDoS Protection: Affordable DDoS protection including Layer 7 mitigation with PoPs in the US, EU and Asia.
      Latest Offer: $14 in Asia DDoS mitigation
    • 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.

      X4B - DDoS Protection: Affordable DDoS protection including Layer 7 mitigation with PoPs in the US, EU and Asia.
      Latest Offer: $14 in Asia DDoS mitigation
    • 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.

      My favourite prime number is 42. - \forall cpu in {intel, amd, arm}: cpu->speed -= cpu->speed/100 x irandom(15, 30) | state := hacked

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

      My favourite prime number is 42. - \forall cpu in {intel, amd, arm}: cpu->speed -= cpu->speed/100 x irandom(15, 30) | state := hacked

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

      My favourite prime number is 42. - \forall cpu in {intel, amd, arm}: cpu->speed -= cpu->speed/100 x irandom(15, 30) | state := hacked

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

      My favourite prime number is 42. - \forall cpu in {intel, amd, arm}: cpu->speed -= cpu->speed/100 x irandom(15, 30) | state := hacked

    This discussion has been closed.