Slashdot Mirror

← Back to Stories (view on slashdot.org)

Starting Today, Google Chrome Will Show Warnings for Non-Logged SSL Certificates (bleepingcomputer.com)

Posted by msmash on from the taking-a-stand dept.

Starting today, Google Chrome will show a full-page warning whenever users are accessing an HTTPS website that's using an SSL certificate that has not been logged in a public Certificate Transparency (CT) log. From a report: By doing so, Chrome becomes the first browser to implement support for the Certificate Transparency Log Policy. Other browser makers have also agreed to support this mechanism in the future, albeit they have not provided more details. This new policy was first proposed by Google engineers in 2016, and was scheduled to enter into effect in October 2017, but was later delayed for 2018.

106 of 172 comments (clear)

  1. this is starting to feel like email by cascadingstylesheet · · Score: 2

    You'll need an SPF record ... oh, and DKIM ... oh yeah, and DMARC ...

    1. Re:this is starting to feel like email by Anonymous Coward · · Score: 3, Insightful

      Gotta keep throwing up those barriers to entry. Can't have the small fry getting in on Google's take, now can we?

  2. Another Google metadata sink? by Anonymous Coward · · Score: 4, Insightful

    So how is this going to be implemented? Every SSL cert is going to be sent to Google for "verification" or is the CT log going to be local and the browser will just search it every time?

    1. Re:Another Google metadata sink? by Anonymous Coward · · Score: 1

      I can hear you was born after IE 6.

    2. Re:Another Google metadata sink? by squiggleslash · · Score: 4, Interesting

      Also what about locally signed certificates, using a corporate or Intranet CA, that's installed on all computers that might use those certs?

      That was, at one point, considered a best practice, but I assume this'll break that.

      --
      You are not alone. This is not normal. None of this is normal.
    3. Re:Another Google metadata sink? by houstonbofh · · Score: 4, Insightful

      I am ready to break all cert warnings entirely. As a networking professional logging into self signed certs all day, the cure is FAR worse then the disease!

    4. Re:Another Google metadata sink? by Curunir_wolf · · Score: 3, Informative

      Also what about locally signed certificates, using a corporate or Intranet CA, that's installed on all computers that might use those certs?

      That was, at one point, considered a best practice, but I assume this'll break that.

      This, from TFA (I know, right?): "Google engineers have also added a Chrome policy flag that allows sysadmins to disable the CT log-checking behavior in instances Chrome is deployed inside an intranet."

      --
      "Somebody has to do something. It's just incredibly pathetic it has to be us."
      --- Jerry Garcia
    5. Re:Another Google metadata sink? by Bert64 · · Score: 4, Insightful

      You shouldn't be doing that, your networking devices should have proper certs or your client system should be configured to trust a corporate CA and the network devices then have certs from that. Chances are your job requires you to have elevated privileges on all manner of important networking devices, if someone was able to MITM you they could steal some powerful credentials.

      The only times you should be logging into a device that uses a self signed cert are:

      1, initial configuration
      2, testing

      In the same vein however, it seems browsers are disabling support for weaker algorithms by default, and preventing you from turning them back on. This represents a significant problem, as there are all kinds of old devices which we still need to access for various reasons.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    6. Re: Another Google metadata sink? by jabuzz · · Score: 1

      Probably on a per host basis, like some of the other exceptions required to operate with the shitty embedded web servers in equipment that don't get updates so are still pre poodle etc. Not really ideal when you have a few hundred or maybee a few thousand.

    7. Re:Another Google metadata sink? by caseih · · Score: 5, Insightful

      Are you joking? Self-signed certificates are secure, arguably more secure than commercial CA-signed certificates because I had to register each and every one with the browser. I created the certs myself. A MITM attack is *instantly* detectable to browsers (and to me), unlike a MITM attack using bonafide signed certificates from a breached certificate authority. Browsers make using self-signed certificates somewhat awkward, which is unfortunate. Firefox tells me, incorrectly, that my self-signed certificate is not secure. That is complete nonsense of course.

      Another secure method is to sign with your own certificate authority. Then you just have to convince the browser once to take your CA cert. Like the self-signed certificates, MITM attacks are instantly detectable. This method is preferable to self-signed certs when you have deal with more than a few.

      In my mind for internal servers and devices, my own certificate authority is far more secure than using something like Let's Encrypt.

    8. Re:Another Google metadata sink? by Junta · · Score: 4, Interesting

      The CA model is particularly bad for 'internal' devices.

      So one, for internal communications inside a home network, the warning is so scary that some devices decline to support https just to avoid the support call because a web browser called the device 'insecure'. Note that https with bad cert is considered 'terribly insecure to the point of blocking the site' and http without any cert whatsoever is 'ok'. Home networks are not going to go through the rigmarole of all this.

      For another, my internal IT department is given the ability to sign a certificate for *any* site I visit to provide support for internal devices. I am not empowered as a user to elect to impose my own nameConstraints as I import the certificate, so to secure access to router.internal.mycompany.com, I give them access to impersonate my.bank.com

      Even when the IT department has ability to sign certificates, either it's going to be uselessly lax (automatic granting of certs for whatever reason) or impractically difficult (every sign requires tedious interactions). Companies are terrible about implementing the right balance internally.

      Assuming you overcame all this, you *still* will get a warning, because that internal IT department isn't going to have it registered in a CT log. If they *do*, then others can audit that log to discern details about their network and they have *another* class of security problem to tackle. Or chrome is deployed with a policy to disable this feature for the sake of the internal devices, *again* coming back to fixing internal network behavior requiring reducing security for the wider internet.

      The problem is that roughly all discussions on this front focus on the typical 'internet' usage and fail to conceive of approaches that would make sense for internal networks.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    9. Re: Another Google metadata sink? by Junta · · Score: 1

      http://www.chromium.org/admini...

      Seemingly on a domain level. So long as you have domain names...

      It would be interesting to treat IP based urls different from name based urls somehow... or at least private and link local addresses somehow differently (unless resolved by name)

      --
      XML is like violence. If it doesn't solve the problem, use more.
    10. Re:Another Google metadata sink? by Junta · · Score: 2

      One amendment, that CT policy is better than I presumed it would be:
      http://www.chromium.org/admini...

      Would have been nice to link in the article, it took me a while to find it. So this provides a more targeted way to relax the CT, which can in turn limit the efficacy of that internal CA, so it seems to be a step in the positive direction.

      Good to see progress being made in limiting the collateral damage enabling https internally can inflict, but it's still in many ways convoluted and an ill fit for how many teams do internal IT.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    11. Re:Another Google metadata sink? by Junta · · Score: 1

      Of course, you would have to securely carry over that cert. At that point it wouldn't matter if it were self signed or not, it's more like managing an ssh host key. Problem is that in practice, people will click 'yes'. Chrome sucks in the regard of not allowing me to mark a specific fingerprint as 'valid' regardless of CA validation.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    12. Re:Another Google metadata sink? by Junta · · Score: 1

      For my part I don't take issue with the concept that at this point encryption and integrity assurance for this sort of traffic, even internal isn't such a bad idea. Aspiring to have an internal network that isn't going to be compromised at the IP or DNS level is a good goal, but to the extent possible success should not be assumed. As such it would be bad form to assume a network to be 'trusted' if at all possible.

      As it stands, not many folks will say 'ssh is stupid, just use telnet' because the key management isn't particularly onerous, despite offering the same sort of security benefits as TLS. People will complain that first contact between a given ssh client and ssh server pair is rarely ever secured, but as far as compromises go, it isn't so shabby. Additionally, SSH in practice has a number of facilities for the willing to do some sort of relevant PKI to mitigate that concern.

      Structurally, the use of certificates in TLS can enable a superset of the way SSH keys can be managed. The private/public keypairs are there as it is in SSH, but with facilities to allow third party trust relationships too. The problem is the state of applications, libraries, and best practices end up making people blindly accepting connection every time or installing very broad CA certificates. I've even heard of one place signing a wildcard certificate and passing the related private key around everywhere so they wouldn't have to 'fool with it' and just have every device have the exact same keypair. TLS is frustrating because of these limitations *in practice*, but I'd rather see a better usage model for the key management than to ditch the concept entirely.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    13. Re:Another Google metadata sink? by Bert64 · · Score: 1

      Defense in depth...
      Hackers are opportunistic, you can do almost everything right but make one tiny mistake at the wrong time and your toast.
      Having multiple layers of defense can mitigate against mistakes, and also against zero-day vulnerabilities in certain components.

      A defender has to cover everything, an attacker only needs to find and exploit one weakness.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  3. Re:Er, what about LetsEncrypt by crow · · Score: 4, Insightful

    No, we need warnings for certificates that aren't trusted. Otherwise SSL does nothing to prevent man-in-the-middle attacks.

    What would be ideal is to support secure DNS with certificates in the DNS. Then you know you have the right certificate and don't need any certificate authorities at all. Of course, you have to trust the secure DNS. so it's just pushing the trust problem down the road.

  4. Registrars treat DNSSEC as an upsell ($) by tepples · · Score: 2, Informative

    No, we need warnings for certificates that aren't trusted. Otherwise SSL does nothing to prevent man-in-the-middle attacks.

    But without a fully qualified domain name, CAs shall not issue a trusted certificate. So we also need a reliable way to provide trustable names for devices on a non-technical users' home network that have a web-based administration interface, such as a modem, router, printer, or NAS.

    What would be ideal is to support secure DNS with certificates in the DNS.

    I agree that DANE would be ideal. But DANE relies on DNSSEC, which has faced practical problems that hinder adoption. Before about a year and a half ago, DNSSEC's root zone key was too short (1024 bit RSA) for browsers to accept as part of a certificate chain. And many domain name registrars bundle zone hosting with a domain, but a lot of these (such as GoDaddy) have charged more for zone hosting with DNSSEC than for zone hosting without DNSSEC.

    1. Re: Registrars treat DNSSEC as an upsell ($) by Monster_user · · Score: 3, Informative

      Why do home devices need to have trusted SSL certs? They are not web facing, and if they have remote capabilities they are typically routed through a service provided by the manufacturer. There is no reason to go through the trouble of key generation and registration against a global root CA.

      Besides, how is a global root CA supposed to verify the connection to a device on a non-routable IP/Subnet?

    2. Re: Registrars treat DNSSEC as an upsell ($) by JesseMcDonald · · Score: 2

      Besides, how is a global root CA supposed to verify the connection to a device on a non-routable IP/Subnet?

      Technically they don't need to. A Domain Validation certificate proves that the certificate holder controls the domain, not the server. Provided you have a (sub)domain you control, you can get a valid DV certificate through a DNS challenge without involving the device at all; the domain's A and/or AAAA records can point to a private or otherwise publicly-unreachable IP address.

      This does require a domain name, however, which is extra hassle and expense which most small-network operators shouldn't need to deal with. For the most common cases this could be provided as a service (like DDNS) by the device manufacturer. However, my proposal would be to bypass the CAs altogether: If the first part of the domain is the base-32 encoding of the fingerprint of the certificate (which may be self-signed) then browsers should automatically consider the certificate Domain Validated. The domain name itself identifies a particular certificate—what more evidence is needed? The "fingerprint domains" will be long, of course, but the initial discovery can be handled via an HTTP redirect or mDNS. Afterward, assuming the user bookmarked the full domain name, they can be sure they're connecting to the same device (trust-on-first-use).

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
    3. Re: Registrars treat DNSSEC as an upsell ($) by tepples · · Score: 1

      For the most common cases this could be provided as a service (like DDNS) by the device manufacturer.

      In the case of server software installed on a Raspberry Pi single-board computer, who is "the device manufacturer"? Raspberry Pi Foundation? Sony? The publisher of the server software?

    4. Re: Registrars treat DNSSEC as an upsell ($) by omnichad · · Score: 1

      Because web traffic can be sniffed, whether on the device or on the network and that compromised network info can lead to harder to eradicate problems. So that's the argument for SSL encryption, at least. Without a cert, how do you know you're even connecting to your own, trusted device?

      Besides, how is a global root CA supposed to verify the connection to a device on a non-routable IP/Subnet?

      It doesn't need to. For one, home routers act as DNS and can present a real TLD that can be verified. The actual IP address does not matter here.

    5. Re: Registrars treat DNSSEC as an upsell ($) by JesseMcDonald · · Score: 1

      In the case of server software installed on a Raspberry Pi single-board computer, who is "the device manufacturer"?

      The person who installed the server software. If you can set up a web server on a Raspberry Pi, you can handle registering and validating your own domain. I did say "the most common cases"—this isn't one of them. The idea is that when someone with little networking experience picks up their Acme Router with an embedded HTTPS administration service, Acme Company provides them with a DDNS subdomain afa7ds9fd.myacme.com, to be printed on the label alongside the default password, and handles the certificate signing process for them.

      Is the domain validation process a hassle for those assembling their own servers? Sure, which is why I suggested an alternative protocol for LAN devices. But it's hardly an insurmountable obstacle, provided the device has an official domain name to validate.

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
    6. Re: Registrars treat DNSSEC as an upsell ($) by Monster_user · · Score: 1

      I'm all for the cert, but I see no benefit in having a third party authentication mechanism just to eliminate some browser warnings. Verfiy the cert, and save it locally to the machine/browser as an exception.

      Perhaps I'm thinking of the issue with SSL certs is that domain wide certs are an extra fee above "A" record specific certs. And A records require an IP, and I wouldn't expect to be able to insert a private class "C" for an "A" record into the DNS records for my domain.

      Talking about having a D-Link or Netgear or Linksys, or Belkin router provide a TLD for itself, that is a bit more than I ever would have considered for a consumer appliance.

      What would that be, a Belkin.Route TLD, with an SSL cert which matches all Belkin routers? How would the cert be protected from maliscious actors? Once the device is physically in the hands of an untrusted party, everything on it should be assumed to be compromised? And the device would have to have a private key stored locally on the device itself to match the public key for the TLD. Which could then be ported to other devices for man-in-the-middle attacks.

      Otherwise how would one manage per person TLDs? Each TLD would require an admin. That admin may well manage multiple sites. Those sites could be single occupant/user sites. Or the admin's home and a secondary site. More importantly who would want to manage consumer devices? If one really had need of validated certs, one could learn, or hire somebody, to implement a system and configure the certs,

    7. Re: Registrars treat DNSSEC as an upsell ($) by omnichad · · Score: 1

      Perhaps I'm thinking of the issue with SSL certs is that domain wide certs are an extra fee above "A" record specific certs. And A records require an IP, and I wouldn't expect to be able to insert a private class "C" for an "A" record into the DNS records for my domain.

      Certs are issued by hostname without regard to what they resolve to (or whether it's an A record or CNAME). And it doesn't matter, because the router can intercept DNS requests and replace its local IP anyway.

      For Netgear, you visit http://www.routerlogin.net/ or http://www.routerlogin.com/ to log into the router. They only need one SSL certificate and no matter how many routers are involved, or how many different IP addresses are involved, the biggest concern is that the firmware doesn't auto-update before the certificate expires. I don't know how they handle the private key, but it could be stored elsewhere than the flash and it may be hard to get at if you aren't able to get flashed firmware to boot.

  5. Scam by rickb928 · · Score: 1

    This seems more and more like an effort to compel website owner/operators to buy into the SSL certificate scheme.

    Revenue.

    --
    deleting the extra space after periods so i can stay relevant, yeah.
    1. Re:Scam by Anonymous Coward · · Score: 2, Informative

      You know you can get a ssl cert for free and have it configured in like 30 seconds with certbot, right?

    2. Re:Scam by rickb928 · · Score: 1

      And join the debate over whether these free alternatives are legit, or fight over whether I should have an EV instead of a DV cert, or wait for say Lets Encrypt get hammered by the cert vigilantes and have to eventually join in and pay so I can be part of the SSL charade?

      If it were so simple.

      --
      deleting the extra space after periods so i can stay relevant, yeah.
    3. Re:Scam by rickb928 · · Score: 1

      Look at the impact of GDPR on the WHOIS database. On the face of it, ICANN merely has to shut down the public database and that leaves everyone in the dark as to the ownership and control of websites. Predictably, law enforcement is squealing the loudest, once again claiming that all will be lost if they are denied the data they so desperately need to protect us. Of course we need no protection from them.

      But truthfully, this renders WHOIS data accessible only to a select few. And that may or may not include law enforcement, governments, intelligence communities, and the unnamed that will circumvent GDPR without a second thought or any real opposition.

      The Web is not well thought of by many who desire power and control.

      --
      deleting the extra space after periods so i can stay relevant, yeah.
  6. internal apps / ipmi / other things that are no on by Joe_Dragon · · Score: 1

    internal apps / ipmi / other things that are not online don't need real certs much less running let's LetsEncrypt with ports open so that runs.

  7. Re:So....F U Proxies and Internal CAs. by tepples · · Score: 2

    If they did care about the end user's security, they wouldn't make stupid changes like not trusting end-user / admin installed CA certs by default.

    Chrome opts in through its network security config file, and Firefox has its own TLS engine. So this affects mostly native apps that use Android's TLS engine.

    Since when does removing / forbidding the user's input on trust somehow boost their security?!?!?

    Malware has in the past added certificates as a means of intercepting apps' traffic. So have governments.

  8. what does this mean for LetsEncrypt? by PhantomHarlock · · Score: 1

    A lot of people, including myself use LetsEncrypt on a CPanel based hosting account to generate certs for a website.

    Are those local, self-signed certificates or something that is registered somewhere? I'd never really paid attention since it just worked and was one less thing to deal with.

    Since it's not retroactive there is no problem now, but wondering what will happen when I generate new certs going forward.

    1. Re:what does this mean for LetsEncrypt? by kiviQr · · Score: 1

      LetsEncrypt submits all certificates as they issue them: https://letsencrypt.org/certif... More details in cert transparency: https://www.certificate-transp...

    2. Re:what does this mean for LetsEncrypt? by Nkwe · · Score: 1

      A lot of people, including myself use LetsEncrypt on a CPanel based hosting account to generate certs for a website.

      Are those local, self-signed certificates or something that is registered somewhere? I'd never really paid attention since it just worked and was one less thing to deal with.

      Since it's not retroactive there is no problem now, but wondering what will happen when I generate new certs going forward.

      In this context certificates perform two functions. 1) They provide a key pair which can be used to encrypt the connection, and 2) They provide a way to have confidence that the person / company on the other end of the network is who they say they are. Any certificate (a free self signed or Let's Encrypt certificate, or an expensive certificate from a commercial CA) can be safely used for just encryption. However if you care about validating who is on the other end self-signed certs are worthless, Let's Encrypt gives low confidence, and you have to spend a decent amount of money to obtain high confidence. What you are paying for when you purchase an expensive EV certificate is the validation process that the CA goes through and the reputation of the CA.

      Note that if you control both ends of the network (and the network itself) such as your computer talking to your hardware device across your network, then a self signed or internally issued certificate is fine.

  9. Re:Er, what about LetsEncrypt by I4ko · · Score: 1

    You don't understand what the certificate is for. It is not the about the half page of data. It is about is the Corporation ABC LTD that is asking for certificate really Corporation ABC. This is because ultimately on the browser side you only see mapping between a certificate and domain name. But the CAs are separate from domain registries, and while domain registries guarantee uniqueness of the domain name, the CAs do not guarantee uniqueness of a certificate.
    With Let's Decrypt any compromise of DNS registration, routing or similar can result in legitimately looking certificate being issued to an illegitimate actor. Having both EV and DV does not work, or rather, in order to know if there is an EV cert, while you are seeing DV served to you, you need another system - this is where CT comes into play.
    IMO all certificates should be EV in the current internet if we want security.
    All certificates being DV (and no EV at all) is also feasible is we don't have CAs as separate entries from domain registries.
    But the current situation - Let's decrypt being able to issue a DV for any EV issued domain, is completely wrong.

  10. Let's Encrypt supports Certificate Transparency by tepples · · Score: 4, Informative

    All websites with a fully qualified domain name qualify for a domain-validated certificate without charge from Let's Encrypt. Every certificate that Let's Encrypt issues is logged in CT.

    1. Re:Let's Encrypt supports Certificate Transparency by Holi · · Score: 1

      Does Let's Encrypt verify identity, I can't find anything on their site about it.

      If a CA is not verifying identity then what use is their certificate?

      --
      Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
    2. Re:Let's Encrypt supports Certificate Transparency by tepples · · Score: 2

      Anonymous Coward wrote:

      Which is exactly why let's encrypt should have their trust revoked. Such lax policies mean even illegitimate sites can get certificates, just look up all the paypal scammers using let's encrypt to show up as trusted.

      By the same reasoning:
      Which is exactly why domain name registrars should have their trust revoked. Such lax policies mean even illegitimate sites can get certificates, just look up all the paypal scammers using domain names to show up as trusted.

    3. Re:Let's Encrypt supports Certificate Transparency by tepples · · Score: 3, Informative

      Does Let's Encrypt verify identity, I can't find anything on their site about it.

      Let's Encrypt is a domain-validating certificate authority, which issues domain-validated certificates. Every such CA verifies that the person requesting a certificate is the same person who controls the domain's DNS. What other sort of "identity" did you have in mind?

      If a CA is not verifying identity then what use is their certificate?

      If a domain registrar is not verifying identity then what use is their domain?

    4. Re:Let's Encrypt supports Certificate Transparency by JesseMcDonald · · Score: 2

      Let's Encrypt doesn't issue EV certificates, so no, they don't verify real-world identity. They verify control of the domain name, just like everyone else issuing non-EV certificates. (Put another way, for DV certificates the domain is the identity.) The distinction between DV and EV certificates long predates Let's Encrypt, and their policies regarding domain validation are no more lax than most CAs'. Stricter, actually, since with LE you have to prove that you still control the domain at least once every 90 days.

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
    5. Re:Let's Encrypt supports Certificate Transparency by AmiMoJo · · Score: 2

      If a CA is not verifying identity then what use is their certificate?

      It allows your connection to the web site to be encrypted, preventing ISPs and other nefarious agents from spying on you to a limited extent.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    6. Re:Let's Encrypt supports Certificate Transparency by thegarbz · · Score: 1

      Does Let's Encrypt verify identity, I can't find anything on their site about it.

      If a CA is not verifying identity then what use is their certificate?

      What identify are you trying to verify? The identify of the machine in question? That's called Domain Validation, and yes Lets Encrypt does that by requiring that you prove that the certificate being issued for domain x is actually for domain x by showing that the machine actually is in charge of domain x by changing something on domain x during the issuing process.

      If you're asking about the identity of the owner of the machine, well that's an Extended Validation certificate and Lets Encrypt doesn't issue those, and to be frank most of the internet doesn't really need it.

    7. Re:Let's Encrypt supports Certificate Transparency by sl3xd · · Score: 1

      Unless Let's Encrypt has changed their policy since I started using them, a certificate has to have an FDQN that's routable on the open internet, and they verify the host(s) are listening on port 443 at least once during the creation or renewal process.

      Let's Encrypt won't issue or renew certs for anybody's internal networks, which severely limits its utility.

      --
      -- Sometimes you have to turn the lights off in order to see.
  11. If you use LE you're fine by tepples · · Score: 2

    A lot of people, including myself use LetsEncrypt on a CPanel based hosting account to generate certs for a website.

    Are those local, self-signed certificates or something that is registered somewhere?

    You could answer that question with five seconds on a search engine. Google Search for let's encrypt certificate transparency produces, as its first result, a document stating the following: "We submit all certificates to Certificate Transparency logs as we issue them."

  12. Re:Er, what about LetsEncrypt by swillden · · Score: 3, Informative

    In answer to your subject, from https://letsencrypt.org/certif...:

    We are dedicated to transparency in our operations and in the certificates we issue. We submit all certificates to Certificate Transparency logs as we issue them. You can view all issued Let’s Encrypt certificates via these links:...

    So LetsEncrypt certs will work fine with Chrome.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  13. CAA records by tepples · · Score: 2

    IMO all certificates should be EV in the current internet if we want security.

    I thought EV certificates were available only to corporations or LLCs, not to individuals. If someone puts up a site to show her personal portfolio, would you prefer to require her to incorporate first?

    But the current situation - Let's decrypt being able to issue a DV for any EV issued domain, is completely wrong.

    That's what certificate authority authorization (CAA) records are for. If a domain owner publishes a CAA record that doesn't include Let's Encrypt, Let's Encrypt will not issue a certificate for that domain.

    1. Re:CAA records by WaffleMonster · · Score: 1

      That's what certificate authority authorization (CAA) records are for. If a domain owner publishes a CAA record that doesn't include Let's Encrypt, Let's Encrypt will not issue a certificate for that domain.

      How does that work exactly?

      If I want a CA to mint me a cert for your domain and I have access to wires over which DNS flows what good is CAA?

      Actual use case where CAA is helpful rather than a dangerous feel good checkbox designed to obscure reality is so small you need a microscope to notice it exists at all.

    2. Re:CAA records by tepples · · Score: 1

      I have access to wires over which DNS flows

      How many routes do you control? Good luck gaining control of all routes belonging to the CA or all routes belonging to both name servers.

  14. Re:Er, what about LetsEncrypt by hispeedzintarwebz · · Score: 2

    Ctrl-F "letsencrypt" Worries eased.

  15. Re:Er, what about LetsEncrypt by Anonymous Coward · · Score: 2

    Certificate authorities are entities that grant certificates. If certs were passed with DNS, a CA would still be needed, even if it's just the DNS server itself.

    Of course then the CA could not be airgapped, and the system as a whole would be more interesting to attackers and have a much larger attack surface.

    Right now there are warnings for certificates that are not trusted. If they do not have a path to a root of trust there is a warning. If they have been revoked there is a warning. If they are self-signed there is a warning.

    This logging system, it does not appear to provide any new services of meaningful value aside from making moderate-knowledgeable people more able to understand a cert and query it's nature. Sounds good but who decides what constitutes a threat? The cert logging policy website indicates CA certificates are strange. They are not. They are mandatory for trust. Apparently the people who made this logging feature get to decide what is and is not a concern to the rest of us, without accepting the fundamental nature of PKI as being strange.

  16. Re: Er, what about LetsEncrypt by Monster_user · · Score: 1

    I think the parent of your comment was saying we need the current system. Given that the GP's goals are pure fantasy.

  17. Secure Contexts by tepples · · Score: 5, Informative

    Why do home devices need to have trusted SSL certs?

    Because Service Workers and several other web platform APIs are restricted to secure contexts per W3C's spec. For example, a browser may restrict the Fullscreen API or Presentation API to secure contexts as a mitigation against phishing by replicating the chrome of the operating system and web browser. In such a browser, the web interface of a NAS on which video is stored will not be able to present the video in the full screen.

    1. Re:Secure Contexts by Actually,+I+do+RTFA · · Score: 1

      How does "this is absolutely the URL you meant to go to" imply "give them the ability to phish by replicating the OS/browser fullscreen"? FFS, just because I want to make sure I'm getting data from somesite.com, doesn't mean I trust somesite.com to run code/be fullscreen/etc.

      --
      Your ad here. Ask me how!
    2. Re:Secure Contexts by tepples · · Score: 1

      It's in case you saved permission for somesite.com to perform these sensitive operations, so that a malicious actor can't exploit these saved permissions by hijacking somesite.com.

    3. Re:Secure Contexts by Actually,+I+do+RTFA · · Score: 1

      Ah, it's to verify a whitelist? Cause that's not how JS works (well, it is on my machine, but...)

      --
      Your ad here. Ask me how!
    4. Re: Secure Contexts by Monster_user · · Score: 1

      Full screen permissions are a whitelist.

      SSL verification ensures the private key of the device, and its domain, matches the public key in the Root CA.

      If the key you have doesn't fit the lock, then don't use the whitelist, as its probably not the real door but a trap.

  18. Re: Er, what about LetsEncrypt by Monster_user · · Score: 1

    Great, another thing to add to my checklist. All "letsencrypt" root CA certs must be checked for and removed, if present, before logging onto an SSL site.

  19. Re:Er, what about LetsEncrypt by Anonymous Coward · · Score: 4, Interesting

    Perhaps, on the other hand, without letsencrypt most of us would not have websites. The poor people of the world would be completely cut off from having their own website, that was not the dream of the internet.

    We cannot be putting restrictions that cut off chunks of the population because they do not meet our criteria, the internet and having your own website should be free and open to all.

    In the bad old days you could only get an SSL certificate if you were incorporated, provided your contact phone number, real name, address, and pay a hefty sum of money. This was completely unacceptable and went entirely against the whole point of the internet. With letsencrypt the playing field has been leveled and this is a good thing and it is keeping the internet operational in the hands of the people.

    Honestly though I am still of the opinion that we should completely eradicate centralized certificate authorities. The certificates should be there to provide encryption which they do whether they come from an authority or not. We should allow free self signed certificates with no warnings. I should not have to link myself up to some 3rd party of any kind to operate my website.

  20. Re:Er, what about LetsEncrypt by tepples · · Score: 2

    Just to get a ballpark figure to guide further discussion of your opinion on Let's Encrypt: How much do you think someone ought to have to pay per year in order to host a personal portfolio site?

  21. Re:Er, what about LetsEncrypt by tepples · · Score: 2

    Let's Encrypt certificates are issued under an intermediate that has always been cross-signed by IdenTrust, an older and more established CA.

  22. Re:internal apps / ipmi / other things that are no by tepples · · Score: 1

    What doesn't make sense is [appliances on LANs] using https with default certificates just to tick of the "it's secure" checkbox.

    That's partly a reaction to browser implementation of Secure Contexts, a W3C spec that reserves certain web APIs for HTTPS sites.

  23. Re:Er, what about LetsEncrypt by sjames · · Score: 2

    Like a standard cert from someone else requires anything beyond rudimentary photochop skills?

    Pinning would do a LOT more for security than the CAs ever have, but since that doesn't present any exciting new business opportunities, it remains unimplemented.

  24. Self-signed certs don't block first-visit MITM by tepples · · Score: 1, Insightful

    We should allow free self signed certificates with no warnings. I should not have to link myself up to some 3rd party of any kind to operate my website.

    Under your proposal, what distinguishes the self-signed certificate that you generated for your domain from the self-signed certificate that the operator of an intercepting proxy (a "man in the middle") generated for your domain, particularly on a client's first visit?

    1. Re:Self-signed certs don't block first-visit MITM by houstonbofh · · Score: 2

      A DNS entry like with e-mail would work.

  25. Multiple routes, expiry, and CT block that by tepples · · Score: 3, Informative

    CAA records are useless when I hijack the DNS in the first place.

    I'm interested to see how you plan to hijack the DNS in a way that evades the following three defenses:

    Breadth of hijacking At what point would you hijack the DNS? A domain-validating certificate authority queries DNS through several Internet routes. How had you planned to hijack them all, especially if the domain's authoritative DNS servers are on different /16s? Expiry Certificates issued by Let's Encrypt expire after 90 days, and organizations may renew them at 60, 73, 85, or whatever day intervals. How long do you plan to keep up the DNS hijacking? Certificate Transparency If a CA issues an certificate to a hijacker, the domain's rightful owner can check CT logs and find your certificate. The policy change described in the featured article encourages CAs to keep their CT logs complete.
    1. Re:Multiple routes, expiry, and CT block that by WaffleMonster · · Score: 1

      At what point would you hijack the DNS? A domain-validating certificate authority queries DNS through several Internet routes. How had you planned to hijack them all, especially if the domain's authoritative DNS servers are on different /16s?

      Owning insecure wire between name server and Internet.

      Certificates issued by Let's Encrypt expire after 90 days, and organizations may renew them at 60, 73, 85, or whatever day intervals. How long do you plan to keep up the DNS hijacking?

      Why would I bother with LE when I can get a 3 year cert from a normal CA using exactly the same approach?

      If a CA issues an certificate to a hijacker, the domain's rightful owner can check CT logs and find your certificate. The policy change described in the featured article encourages CAs to keep their CT logs complete.

      Safe bet they won't.

    2. Re:Multiple routes, expiry, and CT block that by tepples · · Score: 1

      Owning insecure wire between name server and Internet.

      If you own the only wire between the primary name server and the Internet, the CA will notice that the TXT records on the primary name server do not notice the TXT records on the secondary name server.

      Why would I bother with LE when I can get a 3 year cert from a normal CA using exactly the same approach?

      Not needing to whip out your credit card for every hostname that you control.

      The policy change described in the featured article encourages CAs to keep their CT logs complete.

      Safe bet they won't.

      If CAs don't use CT, then as described in the featured article, users of Google Chrome will not be able to use HTTPS on websites using certificates from those CAs, causing web server administrators to seek refunds from said CAs. Is processing a ton of refunds really cheaper than implementing CT?

  26. Re:Er, what about LetsEncrypt by thegarbz · · Score: 1

    IMO all certificates should be EV in the current internet if we want security.

    Every house should be made of solid steel and have no windows either. But total security is impractical and also quite pointless. I don't care about some random hacker taking over all of Slashdot via a sophisticated attack in order to read some user comments. That doesn't however mean I want to blast those comments back and forth across the airwaves in plain text at an internet cafe.

    There are solutions in between Fort Knox and having a house made entirely of paper, and there are needs for those solutions too.

  27. Re:Er, what about LetsEncrypt by thegarbz · · Score: 1

    LetsEncrypt is literally the worst thing to happen to Security on the internet. Its theater and its dangerous.

    Oh? Please expand on your reasoning. What makes Lets Encrypt any worse than any other DV issuer? When you're done answering I'll tell you why they are a damn sight better than most.

  28. Re:Er, what about LetsEncrypt by thegarbz · · Score: 1

    If you're a betting man let's make a bet. I could do with some very easy money.

    Cool I win. I see the green "Secure" symbol at the top of the screen. Oh wait you didn't realise Slashdot has a DV certificate from Lets Encrypt did you... You're funny.

  29. Re: Er, what about LetsEncrypt by thegarbz · · Score: 1

    Maybe you should do it now. Please. And make sure you change your settings so you can't override and then accept an untrusted certificate

    Come post on your reply here on Slashdot when you're done.

  30. Re:Er, what about LetsEncrypt by tepples · · Score: 1

    Let me try to rephrase how I understood DarkOx's comment:

    Issuing TLS certificates based on domain validation, not organization validation, is literally the worst thing to happen to security on the internet. It's theater and it's dangerous.

  31. What does this mean for me? by fluffernutter · · Score: 1

    I run a small operation and usually try to find the $50 SSL certificate so I can keep going for another year. What does this mean for me?

    --
    Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    1. Re:What does this mean for me? by Actually,+I+do+RTFA · · Score: 1

      I run a small operation and usually try to find the $50 SSL certificate so I can keep going for another year. What does this mean for me?

      It depends on your certificate provider. It may require no changes on your part, if your certificate provider logs them in a CT log. If it doesn't you probably want to switch providers. There's nothing you can do to make up for them not doing it/make them (well, you can complain and see if they're fixing the problem soon enough).

      Note, Let's Encrypt (which is free) does log it, so other cert providers probably do too.

      --
      Your ad here. Ask me how!
  32. Re:So....F U Proxies and Internal CAs. by sl3xd · · Score: 1

    When you say this affects native apps that use Android's TLS engine... well, how does that help the enterprise which has users using Android devices?

    I don't see how your response helps sites that use an internal CA, which is a perfectly legitimate activity.

    There are all kinds of places where it's completely unnecessary to pay extortion for a global certificate, yet it's mandatory to have encryption (and mutual validation) to protect sensitive traffic flying around on the corporate WAN. Enterprises also have the right to keep their internal CA's certificates off the open internet -- where does it make sense to provide Google with every hostname in your WAN? What right do they have to the information? They have none..

    Preventing an enterprise from implementing sane, industry-accepted practices is asinine. Admins have every right to install and set trust for internal certificate authorities.

    If anything, I fault Google (and other browser makers) for hiding certificate information - all a user gets without having to go into developer mode is a green padlock and "secure".

    --
    -- Sometimes you have to turn the lights off in order to see.
  33. Re: Er, what about LetsEncrypt by houstonbofh · · Score: 1

    But I understand the GGPs frustration. As a networking consultant, I am having to clickthough self signed certs all day. If there was a good browser that I could globally allow self signed certs, I would switch in a heartbeat! The cure is worse then the disease for me.

  34. Re:Er, what about LetsEncrypt by houstonbofh · · Score: 1

    You don't understand what the certificate is for. It is not the about the half page of data. It is about is the Corporation ABC LTD that is asking for certificate really Corporation ABC.

    Really? I thought it was for encrypting passwords to networking devices so they were not sent in clear text. At least that is what i use them for most of the time. And my self signed certs send my browser into fits of impropriety!

  35. Re:Er, what about LetsEncrypt by thegarbz · · Score: 1

    But like DarkOx I am asking you to explain your reasoning. DV certificates identify the machine on the other end for the purposes of creating an encrypted channel. So explain why its so bad?

    Is SSH nothing more than security theater and we should all either fork out $600 for EV certificates on our servers or just settle with Telnet as well?

    Typically the people who say DVs are theater are those who don't understand the purpose of DVs.

  36. Passwords and Secure Contexts by tepples · · Score: 1

    And [a personal portfolio site] doesn't need to be encrypted

    Let's say a web developer's portfolio site contains demonstrations of web applications, and the users of these web application can create accounts. Without encryption, how should the web developer protect the passwords and session tokens of the users of the web application from interception when exhibiting this application to the public?

    Let's say a web developer's portfolio site contains demonstrations of web applications, one of which uses Service Workers or another web API that has been restricted to secure contexts. Without encryption, how should the web developer exhibit this application to the public?

  37. Re:Er, what about LetsEncrypt by JesseMcDonald · · Score: 3, Informative

    This logging system, it does not appear to provide any new services of meaningful value aside from making moderate-knowledgeable people more able to understand a cert and query it's nature.

    The point of the Certificate Transparency logging system is to make it extremely difficult for any CAs to get away with quietly issuing extra certificates for your domains to state actors and others to enable them to carry out MitM attacks. Since any CA can issue certificates for any domain, this is a real threat which undermines confidence in the entire CA system; it's only as strong as its weakest link. With browsers enforcing CT logging this attack is no longer possible; the certificates will not be accepted unless they are first made public, and any CA that issued such certificates openly would immediately lose its trusted status and be finished as a CA.

    --
    "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
  38. Re:internal apps / ipmi / other things that are no by dgatwood · · Score: 2

    That's partly a reaction to browser implementation of Secure Contexts [pineight.com], a W3C spec that reserves certain web APIs for HTTPS sites.

    I think it's more a reaction to browsers popping up security warnings on all non-HTTPS sites.

    On the one hand, getting public websites to use HTTPS is almost inarguably a good thing. On the other hand, getting intranets to use HTTPS is nearly useless, and getting mDNS devices to use HTTPS is impossible. That last one is going to be a real problem, and I'm really not sure how the industry is going to solve it. The only way I can think of would be to:

    • Define a new mDNS device name field in the certificate spec.
    • Require that all browsers and devices that implement that field use key pinning in lieu of any guarantee of global uniqueness to the names.
    • Require allowing multiple certs with the same name to be pinned with multiple keys (after issuing a stern warning that they are trusting a second device with the same name as an existing device).
    • Possibly require browsers to ignore the expiration date for those certificates (because those devices may not be directly connected to the Internet, and thus might not be practical to re-cert).
    • Possibly define a standard whereby a browser accessing a device with an old certificate can automatically obtain an updated certificate from the same registrar (or its designated replacement) and upload it to the device without user interaction.

    Either way, I'm pretty sure it can't be done practically without making some sort of changes to the standards themselves. That said, I can't be certain of that, because contrary to security best practices, the people who designed the X.509 specification will not make the specification available to security researchers unless they pay $130. So I can only speculate on what the standards say. Aren't standards grand?

    --

    Check out my sci-fi/humor trilogy at PatriotsBooks.

  39. Re:So....F U Proxies and Internal CAs. by tepples · · Score: 1

    how does that help the enterprise which has users using Android devices?

    I don't see how your response helps sites that use an internal CA, which is a perfectly legitimate activity.

    If they're websites, they'd be viewed using either Chrome, whose network security config allows use of user-installed certificates, or Firefox, which has its own TLS engine that also allows use of user-installed certificates. If they're not "sites" but native apps distributed as free software that access an internal HTTPS server's REST API, then the business can download each application's source code from the repository linked on F-Droid and rebuild the APK with a network security config referring to a pinned copy of the internal certificate.

  40. DV doesn't protect against typosquatting by tepples · · Score: 1

    DV certificates identify the machine on the other end for the purposes of creating an encrypted channel. So explain why its so bad?

    Consider this: bankofarnerica.com has an "RN" in it, but it's hard for especially non-technical users to see. Homoglyphs like this can be and have been used in phishing attacks. Under domain validation, what prevents widespread typosquatting the way organization validation can?

    1. Re:DV doesn't protect against typosquatting by thegarbz · · Score: 1

      Nothing, which is also why DV and OV are treated differently. It's why I see "Bank of America Corporation [US]" in the heading of my browser. If I just saw the word secure it would be telling me something different.

      Since we're playing the consider this game:
      Do you live in a house with no door locks or window latches?
      If not do you live in Fort Knox?

      The world is not based on extremes but rather sliding scales. DV certificates serve exclusively the purpose of encryption which is a layer of protection, kind of like having a door with lock on the front. Probably good enough for your house, but like your example, not good enough to protect the stacks of valuables stored in the Bank of America building.

    2. Re:DV doesn't protect against typosquatting by tepples · · Score: 1

      How is an end user supposed to know where on the sliding scale a particular site is supposed to sit?

    3. Re:DV doesn't protect against typosquatting by thegarbz · · Score: 1

      Risk lies with the end user as the end user's usage and ONLY the end user's usage defines the risk. We are posting here on Slashdot. A site that regularly criticises governments and political parties. I am in a western country with reasonable levels of speech protection. My risk is low. What if I were in China or Iraq, or India where Slashdot was recently blocked? There I would have a different risk profile.

      Defining your risk is not something you can outsource to someone else.
      Making everything have the highest risk profile by default is also incredibly draining and wasteful on resources.

      The answer is obviously to have a sliding scale of mitigation and educate people how the sliding scale works. DV certificates weren't bad for security, the 90s/00s era end user education where we say if you see a little padlock in the title bar you are 100% safe was bad for security.

  41. Nor do self-signed certs block DNS MITM by tepples · · Score: 1

    Using a DNS entry as a root of trust will work once DNSSEC support becomes a standard feature in the zone hosting that major domain name registrars bundle with registration. Until that comes to pass, anyone with power to spoof DNS can also spoof your certificate.

  42. Re:Er, what about LetsEncrypt by Actually,+I+do+RTFA · · Score: 4, Insightful

    No, we need warnings for certificates that aren't trusted. Otherwise SSL does nothing to prevent man-in-the-middle attacks.

    Sometimes, not protecting against a MITM attack is fine and I don't need to worry about preventing it. Examples include "being on a LAN and accessing something that is required to be behind https by W3C standards" or "local development of secure services before they're uploaded to test".

    --
    Your ad here. Ask me how!
  43. How to use the dns-01 challenge by tepples · · Score: 1

    Unless Let's Encrypt has changed their policy since I started using them, a certificate has to have an FDQN that's routable on the open internet, and they verify the host(s) are listening on port 443 at least once during the creation or renewal process.

    That is true of the http-01 challenge (though the port is 80). But instead of the http-01 challenge, you can use the dns-01 challenge, which requires a FQDN that's routable on the open Internet and listening on port 53. The machine involved need not be on your private network.

    Let's Encrypt won't issue or renew certs for anybody's internal networks

    Yes it will. Here's the overall procedure to obtain a certificate from Let's Encrypt or another ACME CA using the dns-01 challenge:

    1. Buy a domain, preferably from a registrar whose bundled zone hosting has an API supported by an ACME client's.
    2. Set up zone hosting for that domain on the public Internet.
    3. Using your ACME client, begin a dns-01 challenge with the CA.
    4. Post the response to this challenge as TXT records in your domain. Your ACME client may be able to perform this step automatically if your zone host's API is supported.
    5. Using your ACME client, notify the CA that the response is ready, and retrieve your certificates.

    In step 5, Let's Encrypt will contact your zone host through several routes on the open Internet. Nobody will attempt to connect to your internal network.

  44. Re:Er, what about LetsEncrypt by Bert64 · · Score: 1

    Just having your data "encrypted" is not good enough...
    You need to ensure that not only is your data encrypted, but that only the intended recipient has the decryption key. That's where certificates come in, to verify the remote peer.
    Without certificates or some form of pre shared keys, anyone can sit in the middle and establish an encrypted connection to you, then create a separate encrypted connection to the target you were intending to connect to and watch all the traffic as it gets decrypted by the attacker's machine and then re-encrypted for onward transmission.

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  45. Re:Er, what about LetsEncrypt by JesseMcDonald · · Score: 3, Informative

    how hard would it be for them to work a command line flag like -gov to not log the certificate they are forging?

    Not hard at all, but it doesn't matter since browsers won't accept the certificate if it isn't in the log. That's the point of making CT logging mandatory.

    --
    "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
  46. Re:Er, what about LetsEncrypt by I4ko · · Score: 1

    Nope. Keys are for encryption. Keys wrapped and bound to identity are called certificate. Gutting what the certificate meant, just to get to keys, is extremely stupid.

  47. Re: Er, what about LetsEncrypt by Darkk · · Score: 1

    Good catch as I didn't know slashdot.org actually use Let's Encrypt SSL service. Figured it's a commercial website would use something like GoDaddy to provide high level of trust.

  48. Re: Er, what about LetsEncrypt by thegarbz · · Score: 1

    Figured it's a commercial website would use something like GoDaddy to provide high level of trust.

    Are you aiming for a +5 Funny? Because That's how you get a +5 Funny. I hope mods are watching :)

  49. Only new SSL certs need to be in a CT log by rufey · · Score: 1

    This is not retroactive, meaning SSL certificates that were issued prior to May 1, 2018, will continue to work without warnings, even if they are not in a public CT log.

    From TFA: The new CT policy is not retroactive. This means that older certs issued before today that have not been recorded in a CT log will continue to work. But if a CA has issued a new SSL cert starting today and has not recorded it in a public CT log, Chrome will show an error.

    For those who use self signed certs for whatever reason (I do for some things), simply turn the clock back prior to May 1, 2018 and issue a new cert that has a long expiration date (say 2+ years). Until they make this retroactive, those certs will not generate an error.

    Lets Encrypt and other free services are fairly easy to use, but may not work well with internal-only domains, as they do verification via having you either add a specific DNS entry or a web page on the site's web server, and you have to renew it every 90 days (Lets Encrypt issues SSL certs for a 90-day validity period, others may have a longer validity period).

    1. Re:Only new SSL certs need to be in a CT log by rufey · · Score: 1

      And further, Devon O'Brien, a Google Engineer working on this, posted this back in October 2017 (emphasis mine):

      Since January 2015, Chrome has required that Extended Validation (EV) certificates be CT-compliant in order to receive EV status. In April 2018, this requirement will be extended to all newly-issued publicly-trusted certificates - DV, OV, and EV - and certificates failing to comply with this policy will not be recognized as trusted when evaluated by Chrome. Certificates issued from locally-trusted or enterprise CAs that are added by users or administrators are not subject to this requirement.

      https://groups.google.com/a/ch...

  50. Corporate CAs? by WaffleMonster · · Score: 1

    I don't use chrome but I do some testing with it every once in a while.

    All of these security bullshit droppings in chrome is going to cause error fatigue for problems that are either not problems at all or worthless to most users.

    All kinds of shit get errors that only appear in chrome. Certs that have a CN but not SAN are flagged only in Chrome for no sane reason.

    Well known sites like https://www.kernel.org/ are flagged as insecure. Again only in chrome.

    All resources protected by internal/corporate CA's I assume will now be flagged because none of them participate in log transparency.

    I don't have a problem with CT if deployed properly /w user controls and privacy to avoid CT being another excuse for data leakage with widespread coordination and agreement among all stakeholders. But that isn't what happened here. Specifically:

    Only Google requiring it with not much in the way of industry buy in.

    RFC6962 is an experimental RFC not a standards track document.

    Chrome requiring Google CT servers is over the top abuse of power.

  51. Re:Er, what about LetsEncrypt by crow · · Score: 1

    I'll admit I don't know the technical specs, but it sounds like a solid solution. I would like to hear if anyone knows if there's a technical reason for not moving forward with it, or if it's just money and politics.

  52. Re: Er, what about LetsEncrypt by swillden · · Score: 1

    something like GoDaddy to provide high level of trust

    I turned my head just in time. So now I have a mess to wipe up, but don't need a new keyboard. It was a near thing.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  53. Re:So....F U Proxies and Internal CAs. by sl3xd · · Score: 1

    And if they’re apps that are not open source, and it accesses the internal HTTPS server’s REST API (with an internal CA Certificate)?

    For example, an enterprise install of HipChat, with users using Atlassian’s HipChat for Andoid?

    It sounds like the App will be broken, and users will have to use the web interface (and not get things like notifications).

    --
    -- Sometimes you have to turn the lights off in order to see.
  54. Re:So....F U Proxies and Internal CAs. by tepples · · Score: 1

    And if they’re apps that are not open source

    Develop, or fund the development of, a free replacement for said non-free app. Or file a support ticket with the application's publisher to whitelist your company's internal server's certificate in a customized build of the application for your company.

  55. another change by jrumney · · Score: 1

    Nice to see that you can view the certificate details by clicking on the "Secure" icon in the address-bar again. It was insane when they hid that under Developer Tools so you had to jump through hoops to check why a site was showing up as Insecure.

  56. Re:So....F U Proxies and Internal CAs. by sl3xd · · Score: 1

    In other words, a giant "F U" to enterprises that use internal CA's: Google is breaking working applications, and giving no solution that doesn't cost a significant investment of time and effort.

    Got it.

    --
    -- Sometimes you have to turn the lights off in order to see.
  57. So the PKI isn't that good after all. by ebvwfbw · · Score: 1

    WTH Why is this even needed. SSL Certificates are just that, a certificate. From trusted source. So why do we even need this.

    Are you really sure this certificate is ok?

  58. Re: Er, what about LetsEncrypt by Monster_user · · Score: 1

    Misunderstood. Never heard of LetsEncrypt before, and it sounded, from the parent of the post I replied to, like LetsEncrypt was not verifying against actual public domains. Ie. Essentially blindly trusting all self-signed certs rendering the purpose of a Root CA ineffective. Given that another verification methodology was mentioned, and most of the context here seemed to be pushing LetsEncrypt for home devices and such, which would not normally be matched with public registered domains, I misunderstood.

    In reviewing the certificate chain for Slashdot, Let's Encrypt is an intermediate authority, and not a root CA.

    I will step back and reassess the situation with the appropriate information.

  59. Re: Er, what about LetsEncrypt by thegarbz · · Score: 1

    Yeah I can provide you a bit of information. Lets Encrypt is a project that provides free SSL DV certificates. It's a CA that is cross signed by IdenTrust (giving it support in all usual systems), but also has it's own root which isn't widely used.

    A lot of the flack Lets Encrypt gets comes from a few silly misconceptions:

    1) They are free. Free means no people involved. Therefore it must be bad because where is the trust right?
    2) They only issue DVs. CAs that only issue DVs can't be trusted because they aren't doing all the necessary checks right?
    3) I was able to get a DV without sending through my passport or other ID, therefore they aren't doing the checks right?
    4) Lets Encrypt gives you certificates in seconds, so it can't be through right?

    All three of those basically come down to a misconception of what DV proves: That a machine actually controls content on a domain. Nothing more. Lets Encrypt achieves this free of charge through automated scripting. If you want a certificate for you host, the script works with the Lets Encrypt API through a challenge and response type exercise proving that the host the script is running on is able to modify a specific file in a specific folder associated with the domain that is having the DV issued. The certificates are only valid for 3 months at a time.

    They do something similar with a wildcard certificate but rather than modifying just a file being served up by the host it also needs to modify a DNS record to prove the machine controls the entire domain.

    Some people say that without humans in the process it's not a good verification. I say that because there are no humans in the process it's not a good verification.

    Though one legitimate criticism is that this process is vulnerable to hacking in that if you can take control of routing you can pretend to be the domain owner for the purposes of fraudulently obtaining a certificate. My response to that is that DV certificates are like the door lock to your house and not a bank vault. Just like your house is susceptible to a brick through the window doesn't mean door locks don't serve a purpose, and if you have a bank vault maybe a DV certificate is not for you.