Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



Forgot your password?
typodupeerror
Encryption Security

New SSL Server Rules Go Into Effect Nov. 1 92

Posted by Soulskill
from the encrypt-your-calendars dept.
alphadogg writes: Public certificate authorities (CAs) are warning that as of Nov. 1 they will reject requests for internal SSL server certificates that don't conform to new internal domain naming and IP address conventions designed to safeguard networks. The concern is that SSL server digital certificates issued by CAs at present for internal corporate e-mail servers, Web servers and databases are not unique and can potentially be used in man-in-the-middle attacks involving the setup of rogue servers inside the targeted network, say representatives for the Certification Authority/Browser Forum (CA/B Forum), the industry group that sets security and operational guidelines for digital certificates. Members include the overwhelming bulk of public CAs around the globe, plus browser makers such as Microsoft and Apple. The problem today is that network managers often give their servers names like 'Server1' and allocate internal IP addresses so that SSL certificates issued for them through the public CAs are not necessarily globally unique, notes Trend Micro's Chris Bailey.
This discussion has been archived. No new comments can be posted.

New SSL Server Rules Go Into Effect Nov. 1

Comments Filter:
  • Why? (Score:5, Insightful)

    by Ark42 (522144) <slashdot@@@morpheussoftware...net> on Friday July 25, 2014 @01:15PM (#47533231) Homepage

    Why are people using public CAs and purchased certificates for private networks?

    Wouldn't it make more sense to set up your own internal CA, or at least just force via policy certain certificates onto each computer's browser as trusted?

    • Re:Why? (Score:5, Funny)

      by Anonymous Coward on Friday July 25, 2014 @01:28PM (#47533363)

      Also, why were the CAs *ever* granting these certs? And is it too late to get one for "localhost"?

      • Re:Why? (Score:5, Insightful)

        by El_Muerte_TDS (592157) <elmuerte AT drunksnipers DOT com> on Friday July 25, 2014 @03:12PM (#47534237) Homepage

        Because of money.

        • To be slightly more accurate and less cynical, because their customers asked for one, and because there were no particular rules or guidelines laying out what to do with such requests thus no reason to refuse. Sure, any given CA could refuse on principle, in which case that customer would go to a competitor. That's why the CA system is regulated by browser/OS makers - to keep standards high in the presence of competitive market forces that would otherwise optimise for convenience.

    • Re: Why? (Score:5, Insightful)

      by tysonedwards (969693) on Friday July 25, 2014 @01:29PM (#47533367)
      If all of those devices were centrally managed, sure. Let's say that instead you are a college, with dorms, and an internal network that those in the dorms can use with direct access to things like Mail and whatever, or a BYOD scenario where users are allowed to use their cell phones to get email and even be on wifi, but you want to respect your employees privacy on their private purchased devices rather than adding them to an MDM.

      Do you really want to bug those user's repeatedly with self signed cert validation prompts or just say "okay, $30 / year is worth avoiding the helpdesks"?

      In most cases, yes, a CA and group policies makes the most sense though and should be the answer. There are just a few fringe cases where it is easier to pay the few bucks than waste the time explaining why the user is in fact safe and just press okay.
      • Re: Why? (Score:5, Informative)

        by QuietLagoon (813062) on Friday July 25, 2014 @01:47PM (#47533545)

        ...Do you really want to bug those user's repeatedly with self signed cert validation prompts or just say "okay, $30 / year is worth avoiding the helpdesks"? ...

        They are bugged only once, and then they accept the cert locally. Or the college provides an easy way for the BYOD people to acquire the college's cert.

        There is no need for an official CA to issue a cert for Server1 at IP address 10.2.1.2. No need whatsoever. And, as proof of that, starting in November, the official CAs will stop issuing those types of certs.

        • by Anonymous Coward

          Are you connecting to that self signed cert that is university owned or that self-signed cert that is setup by my evil laptop on the wifi network?

          For trust to occur you need authentication as well as authorization. The external CA authentications your connection, which enables you to safely authorize yourself with the remote party.

          Security 101, don't use self-signed certificates if you cannot control the CA (eg an internal network where you import your internal CA into all of your devices). With BYOD you

          • Are you connecting to that self signed cert that is university owned or that self-signed cert that is setup by my evil laptop on the wifi network?

            [...]

            With BYOD you simply cannot use a self-signed certificates. Your potential attack surface than increases.

            That's why the previous poster said "Or the college provides an easy way for the BYOD people to acquire the college's cert."

            You don't have to trust any self-signed certificate that the web server throws at you. You go to the official, public website of your uni/work/whatever (or to the IT dept. if they want to do this by hand), and grab the CA cert there. You trust this website, it can have a regular certificate issued by any public authority, and using this newly downloaded cert. as a CA, you can safely co

          • by Albanach (527650)

            The parent is spot on. If you need to self-sign, then you need the client to trust your signing authority, not simply to trust your self-signed certificates.

            Asking them to trust your certificates means teaching them to ignore and click through an important security warning. It not only poses a danger to your users in their internet use elsewhere, but also to your own servers as someone can set up a MITM attack and you have already trained your users to ignore the warning presented by the browser.

            Widely trus

            • Agree with this completely.

              Even if the application is only accessible within the private network, there is nothing stopping them from using their external DNS (eg. someapp.bigcorp.tld) and point it at an internal IP, then properly set up an SSL Certificate. But if it is only accessible within the private network, do you really need it wrapped up in SSL at all?

              Using poorly configured hostnames only accessible within the network is plain stupid. At the /very least/ set it up on a domain within the network, so

              • But if it is only accessible within the private network, do you really need it wrapped up in SSL at all?

                Yes, for reasons of privacy from people in other departments who don't deserve access to particular pieces of information. For example, a hospital regulated under HIPAA wouldn't want a surgeon snooPING AS usual [youtube.com] on the health information of patients who aren't hers.

              • by fishbowl (7759)

                Many situations require the encryption of SSL without necessarily requiring the authentication of SSL. This is the case when the risk is more from something like accidentally or casually disclosing sensitive information and there is little or no risk of intentional attack, but where there are liabilities for routine exposure. This scenario isn't really a job for SSL, but what else do we have to work with?

            • Re: Why? (Score:4, Informative)

              by Z00L00K (682162) on Friday July 25, 2014 @04:24PM (#47534811) Homepage

              Assuming the CA can be trusted.

              I'm not trusting the CAs that exist to not reveal key data to NSA or other organization.

              • by jrumney (197329)
                The CA doesn't get key data.
                • by Z00L00K (682162)

                  They get enough to be able to provide a man in the middle attack.

                  • by ruir (2709173)
                    And to break far more easily the encrypted traffic.
                  • by jrumney (197329)
                    Please expand. Are you saying that the CA signed certificate can contain two public keys, and that browsers will encrypt the session key such that either key's corresponding private key can be used to decrypt it?
                    • by Z00L00K (682162)

                      No, but the CA can provide a certificate suitable for a man in the middle attack that is masking itself as the real server if the CA is compromised.

                      That's the weakness with the existing system of public certificate authorities. There are three points that can be compromised instead of two as soon as you have a public CA signing the certificates.

                    • by jrumney (197329)
                      And if the CA was not in the loop, the CIA could create such a certificate themselves, and it would be just as valid as the certificate created by the real owner to the outside observer. So how is adding the CA increasing the vulnerability again?
                    • by Z00L00K (682162)

                      That would only work if one of the end points are compromised, so by leaving out a third party CA you decrease the sensitive points from three to two. It of course requires the end point owners to have a correct key handling and key exchange, but that is no different from having a CA.

                      The only time a CA is useful is if the two communicating parts don't know each other, but in the matter of a bank the person is already a customer and therefore a key exchange can be done at a bank office.

                  • by tlhIngan (30335)

                    They get enough to be able to provide a man in the middle attack.

                    If you can do that with a CA, I say you have far more interesting technology than signing a cert.

                    A certificate is basically a signed public key. You give the CA the public key, they sign it, which says "I, the CA, certify that this public key belongs toe XYZ Inc".

                    That's it. You don't sign private keys (they remain on your server, after all), and your server hands out the certificate during initial security setup. The client looks at the certif

            • by ruir (2709173)
              In a university, *for* internal sites, they can distribute the root certificate to desktop via AD logins for instance, or putting it on a site. Profiles are also a way. They can be distributed in profiles say for wifi use, and it is debatable whether using a private CA for wifi authentication is actually more secure.
        • by blueg3 (192743)

          They are bugged only once, and then they accept the cert locally.

          Not necessarily. On Chrome, for example, accepting a self-signed cert long-term isn't the default behavior. Even that isn't a great idea: you have no knowledge of whether the self-signed cert is legitimate or not without a substantial out-of-band communication of technical information to nontechnical people, which isn't cheap. A college network is a good example: it should be treated as a hostile network, so MitM against a self-signed cert within your private network is very much a reality.

          Or the college provides an easy way for the BYOD people to acquire the college's cert.

          Doing that at a l

        • There is no need for an official CA to issue a cert for Server1 at IP address 10.2.1.2.

          But certificates are given for names , not addresses, and you don't specify any address in the request.

        • And, as proof of that, starting in November, the official CAs will stop issuing those types of certs.

          Not quite. As of November, the official CAs will claim that they've stopped issuing those types of certs. When something like the SSL Observatory [eff.org] points out that they're still issuing them, they'll say that this (and the other 8,192 times they did it) was a one-off mistake and they've updated their policies to make sure it never happens again. Then when they get caught again they'll say that it was test certificates that accidentally escaped. After that, they'll stop responding to reports. And we'll al

      • by unrtst (777550)

        I have trouble seeing any of the justifications for getting a public CA cert for a name like "Server1" with an internal IP.

        You could use your own internal CA, as others have noted. There is overhead to doing so and, being lazy, just buying the public cert may have seemed like an option.

        However, one could simply use a real DNS entry, and all would be fine. Ex. server1.int.my-domain.com. Setup the "int.my-domain.com" on dns servers that all your internal hosts can see (they're all internal, so that can't be T

        • by cr0nj0b (20813)

          Exchange is a big reason for getting a certificate that contains internal domains.
          You get a single UCC Certificate that contains mail.domain.com and mail.company.local
          first result from google for UCC cert
          http://support.godaddy.com/hel... [godaddy.com]

      • by jythie (914043)
        There are also a few edge cases (in windows) where accepting a self signed certificate requires fiddling with the registry. Microsoft designed a few of its services with the idea that everyone would have a CA signed certificate.
      • Do you really want to bug those user's repeatedly with self signed cert validation prompts...

        No - you set up a Web base CA that let's them request certificates (and that CA ensures that they are only valid for local-network names), and publish the root certificates on that site, with instructions for how the users can load them into their systems/browsers.

        Then they don't get prompted for locally-issued certificates.

    • by gregsmac (945663)
      I think it is because for 300 bucks a year, you can have a CA issue a cert without having to manage a cert server in your own environment. Not to mention hardware cost, server license cost, maintenance cost...etc.
      • by LiENUS (207736)

        Not to mention hardware cost, server license cost, maintenance cost...etc.

        I dont think a cert server works the way you think it does.

        I mean technically it has costs... but theres not a lot of reason you can't use a $300 convertible tablet pc handle your ca cert virtually indefinitely, it doesn't have to be turned on after you finish signing certs until its time to sign another batch...

        • by gregsmac (945663)
          That's crazy talk. maybe in a small shop a tablet PC could be entrusted to such an important role. In the larger environments I don't think that would fly. Risk team would never allow it.
          • by unrtst (777550)

            That's crazy talk. maybe in a small shop a tablet PC could be entrusted to such an important role. In the larger environments I don't think that would fly. Risk team would never allow it.

            ... is that the same risk team that would authorize the purchase of a public cert for "Server1"?

            I think the original point was that it takes almost nothing to sign certs. There need not be any significant investment.

          • by afidel (530433)

            So you use a VM, marginal cost is near zero for a 4GB VM in todays world.

        • it doesn't have to be turned on after you finish signing certs until its time to sign another batch...

          To be fair, with OCSP you need something that's online all the time your certificates are used. But unless you have hundreds of peoples checking your certificates simultaneously, any low-end contraption can handle it.

    • I have to confess, I'm pretty mystified. For our own internal servers, I have my own CA, and can see no reason why I would want to have someone else sign internal certs.

      Sounds like yet another way in which the commercial CAs scam stupid CIOs out of cash.

    • by cps42 (102752)

      Without addressing the correctness of the process, the Microsoft Exchange documentation suggests a SAN certificate for the Exchange servers that includes the public names and internal names on the same certificate. Lync does the same thing.

      While this reduces services and split-naming confusion, it also puts your internal naming convention in the public certificate. People do it because MSFT says so. This Exch2007 article (Yes, old, but the first link in google. There are more examples.) says to put the Net

      • by cr0nj0b (20813)

        mod parent up. this is an important point for Microsoft shops.
        changing your internal Active directory structure from company.local to ad.company.com is a major pain and error prone.

    • SAN certs allowed you to use one cert for both internal and external services.
      http://www.digicert.com/subjec... [digicert.com]
      one cert registered to the Public and verifiable FQDN, with Alternate names in the cert something.local.

      Internal CA's are very hard to deploy with BYOD these days.
      (Bring Your Own Device)

    • by mysidia (191772)

      or at least just force via policy certain certificates onto each computer's browser as trusted?

      That works fine for Internet Explorer on Windows via group policy.

      It doesn't work for Firefox or Java (separate private trusted certificate storage databases).

      More importantly: It doesn't work for iPhones, Androids, or macs accessing intranet resourses, or that require a valid certificate to setup Activesync connection.

    • by ruir (2709173)
      Because the whole certificate chain of trust business is a sham, so let be stupid and waste money on your private network too.
  • by Sloppy (14984) on Friday July 25, 2014 @01:18PM (#47533267) Homepage Journal

    Who are these people, that would give a damn about this change?

    You don't need an intermediary not-you authority for this job. And in fact, using one can only possibly decrease the security, in the best case scenario. Even the worst most incompetent company in the world, would make a better CA for its internal servers, than the best, most trustworthy public CA.

    • by Anonymous Coward

      Cheaper and easier to convince the PHB to buy a certificate signed by a public CA, than install your own CA certificate on every browser in your company.

      • Cheaper and easier to convince the PHB to buy a certificate signed by a public CA, than install your own CA certificate on every browser in your company.

        Then your organization's IT department needs to learn about Group Policy and its counterparts on other common personal computing platforms.

        • by dkf (304284)

          Cheaper and easier to convince the PHB to buy a certificate signed by a public CA, than install your own CA certificate on every browser in your company.

          Then your organization's IT department needs to learn about Group Policy and its counterparts on other common personal computing platforms.

          Yeah, but getting all that to work when dealing with the reality of BYOD in many organisations (universities have a particular problem with this) is massively more complicated and expensive than ponying up for an externally-signed certificate. Heck, even getting an externally-signed local CA certificate is cheaper. Group policy (and equivalent) works relatively well for desktops and other wholly-owned devices, but ceases to be nearly so useful once you have to deal with anything external, and that's more

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Not at all true on several fronts:

      1) Getting security right is actually more difficult than most people imagine. Joe Blow random IT guy *thinks* they know how to do it - and in most cases they are wrong. It may be "hip" to dis public CAs, but you've not seen security failures until you have a random IT person trying to setup something like this as an internal side project.

      2) You are completely disregarding the level of effort and implicit security risks involved in trying to publish a 'private CA' record

  • by Anonymous Coward

    So the people responsible for enforcing the administrative details of enforcing the spec are finally realizing they have some work to do?

  • This may cause big problems for many of the existing systems out there. How do they determine internal names? Does it require a .com? Will it take into account any new top level domains that opened up? What about certificates for various systems that do not require domain names for communication (I.E. ADFS Signing/Encryption Certificates).

    I think it should be required to not mix internal and external names in certificates, but to ban them completely is going to break many things. I know by default Exchan
    • by swb (14022)

      You can change the names used by Exchange so that you completely avoid any ".local" addresses. About the only kludge (which is usually already in place) is a being able to resolve public domains to internal addresses.

  • What a junk article - no explanation of what's actually going on and no link to a standard.

    It sounds like what they're inferring is that you need server.example.com, not server.local or server.somemadeupcrap.

    I think most of us cleaned up that cruft when BIND 9 came out with views support.
        This shouldn't impact anybody who hasn't been dragging their heels on fixing their infrastructure for more than a decade.

    • by ruir (2709173)
      Yep, split DNS fixes a lot of headaches, and "optimizes" a lot of internal traffic. No need for the traffic to go to firewall to talk to a NAT IP and come back to the internal network.
  • Of hosts, we could even call the file 'hosts'. Then, periodically, you pull a copy from the master to have locally. Simply set up a governing body to arbitrate name clashes (like 'mailserver') and you're good to go!

  • by dskoll (99328) on Friday July 25, 2014 @03:40PM (#47534469)

    I'm curious as to what documentation the CA's required for you to prove that you own localdomain or 192.168.2.22.

  • The Slashdot article hints that a change would be effective per November 1st 2014. Does anyone know where that date originates from? The new CA/B Baseline Requirements 1.1.8 [cabforum.org] (.pdf) states:
    • 2015-11-01 Issuance of Certificates with Reserved IP Address or Internal Name prohibited.
    • 2016-10-01 All Certificates with Reserved IP Address or Internal Name must be revoked.

    And:

    As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject com

    • by Gerv (15179)

      CAs normally issue certs with 1-year validity. As they may not expire later than 2015-11-01, CAs will mostly stop issuing them on 2014-11-01. I guess you could ask them to cut a cert with a special, shorter lifetime but that would be hassle (and therefore extra cost).

Loose bits sink chips.

Working...