back to article SSL authority stops issuing certificates following breach

Yet another web authentication authority has stopped issuing secure sockets layer certificates after discovering a security breach that allowed hackers to store attack tools on one of its servers. Netherlands-based KPN Corporate Market said it was taking the action while it investigated the compromise, which may have taken …

COMMENTS

This topic is closed for new posts.
  1. Big Al
    Black Helicopters

    Compulsion

    "And with some of the authorities residing in countries such as China, it's not a stretch to imagine them being compelled to issue fraudulent certificates."

    Pretty much any government with a need/desire to do this will find a way of doing so, I would have thought...

    1. Christoph
      Black Helicopters

      I don't think it's much of a stretch to see US Homeland Security doing exactly that.

      1. James 100

        Of course Homeland Security HAVE persuaded Verisign to cooperate in domain hijacking in the past - hardly a stretch for them to extend that from DNS records to SSL.

        Disturbingly, while the SSL-cert-via-DNSSEC extension avoids the CA hole, Verisign as .com operators could still pull the same stunt for DHS in that case as well. I'm not the only one seeing a need for rogue-government-countermeasures here, am I?

  2. FredScummer
    Mushroom

    So True

    Although we pride ourselves on being whiter than white there is always going to be an element of trusting people/organisations that you assume to be completely legit. It only takes one snake in the process to open pandora's box.

    However, thank goodness we can rely upon El Reg to look after our interests.

    1. Tomato42
      FAIL

      Default deny

      Making the CRL (or OCSP) mechanism a white-list not a black list it is now would make it possible for a 3rd party to check what certificates have been issued.

      But that would require for CAs to care about security. While in reality they care for money.

      The whole system was a failure since its inception.

      1. Anonymous Coward
        Anonymous Coward

        @Tomato42

        "The whole system was a failure since its inception."

        I disagree, the system itself is pretty solid. Its the way people and companies use it which makes it look as a big failure. Don't blame the system itself for bad implementations.

        Just take a look at OpenSSL and its default config file. It offers one section ("CA_default") and as such most people simply use that without bothering any further. You can make a self-signed certificate and that's it.

        Hardly anyone will bother by taking a look at all the different possibilities which you have; code signing, server authentication, allowing to apply signatures (the certificate is considered to be used as a ca itself) or simply as (public key) based encryption.

        All of that (and more) is possible using X509 through openssl yet hardly anyone sets up something like this. Most certificates which get released are basically setup as "can do everything". While security can come with diversion; making sure that a code-signing certificate cannot be used for, say, authentication or encryption.

        And that's not even touching subjects as CRL's.

        Heck; even Microsoft falls into this hole (somewhat) when looking at their implementation in their 2k3 server. When you check up on the properties of a CA setup you'll notice that the default extensions (for CRL locations) often point to non-existing locations (short: C:\CAConfig contains your certificate and gets shared as "CertConfig". C:\WINDOWS\system32\certsrv\CertEnroll contains all the stuff which the 'certification service' sets up. Its not shared. Funny how it will - by default - put a CRL location of "file://\\server\CertEnroll\certificate.crt" in the config).

        2k8 restricts this more to AD usage (afaik you can no longer use it stand alone) but still...

        Just because people don't use the system to its full potential doesn't make the system bad IMO. Who said that security was to be easy?

  3. Ramazan
    IT Angle

    in countries such as China

    Do they have equipment for "MITM lawful intercept" though? I'm pretty sure they do, but I'd like El Reg to name particular network equipment vendors and certain models and features of the equipment they sell to China

    1. Turtle_Fan

      Why would the Chinese buy abroad for something as important to them as this?

      As for brand names Huawei and ZTE are the most visible ones.

      http://wwwen.zte.com.cn/en/products/core_network/mobile_core_network/mobile_circuit_switching/201107/t20110704_241710.html

      Having said that, SS8 and a few others seem pretty busy in China.

  4. hyakuhei

    Coerce a CA?

    You'll find that the Chinese Internet Network Information Centre (CINIC) is a trusted CA in a number of CA bundles, as are a number of other nation-state run CAs.

    http://lwn.net/Articles/372264/

    No need to twist anyone's arm there I'm afraid, sure there's a deniability angle, but if you want subvert a certificate without it being attributable to your nation you go after some crappy CA in another region, not twist the arm of a CA in your own country.

  5. s. pam Silver badge
    Headmaster

    If you just blindly trust all CA's you're on drugs!

    Look folks, it is not that hard to do a little research, read through the CA's stored with your browsers and remove (a) foreign, E.G. China based ones if you don't do business with them, and (b) zap CA's that end up in the press like this latest vendor.

    It is a huge Fools Paradise when you just blindly accept certificates with out examining them -- YMMV.

  6. David Roberts
    Holmes

    Decent security costs far too much - up front.

    In a previous life I worked for a major UK Telco on many things including OSI software and PKI (Public Key Infrastructure).

    In both cases IMHO the standards were exhaustively thought out by paranoid boffins who lived in an abstract world but were very good at theorising obscure threats and potential problems.

    With OSI the standards were more or less ignored in favour of the RFCs developed on the pricnciple that we are all good chaps so let's work together as easily as possible.

    Loads of adopters because it was cheap and easy.

    Followed by years of retrofitting the things that the OSI specifiers had thought out but which weren't cost effective to implement on day one.

    Implemented, obviously, because security weaknesses had been exploited and financial damage had been suffered.

    With PKI the software to build a CA was readily available and almost anyone could issue certificates.

    The big and horrendously expensive challenge was to implement the infrastructure in a secure manner so that nobody could spoof credentials and no unauthorised person could create valid credentials.

    All the cost and hard work was in the physical security including network separation and in complex process and procedure to validate all applicants for certificates.

    So no surprise that corners have been cut all over the place - it just costs too much to implement and police.

    Until it all starts costing so much money that the problems have to be fixed.

    Anyone hear the sound of yet another stable door swinging in the breeze?

    I am puzzled as to why the regular in depth scans on the CA systems with industry leading AV software to check for virus and other malware attacks didn't locate the threats until after someone noticed the network doing bad things.

    Or is this another thing that was judged too time consuming and expensive?

    One further rambling on PKI - if everyone who had an email account also had to have a certificate to go with it and only signed email from a current good CA was allowed through major mail hubs then SPAM could be cut down enormously.

    Cost a bit to implement though, wouldn't it?

    I wonder when this will cost in?

  7. -tim
    FAIL

    Who could have predicted this?

    Who would have thought selling random numbers would be so hard?

    1. Bob Hoskins
      Holmes

      Agreed - it's such an easy problem to fix I'm actually afraid I might hurt myself writing it down.

  8. dpGoose
    Paris Hilton

    That's a fair comment s. pam but how do you verify the ones you keep are trustworthy? Unless you are test their security etc yourself then at some point you have to rely on someone else to say they are ok.

  9. Bob Hoskins
    FAIL

    The Dutch are useless at security

    See title

  10. David Haig

    @s.Pam

    No offence, but the people who read El Reg know what a CA is - the targets for any SSL/CA fraudulent attack don't - for example they just want to go shopping on the internet and think it's as safe as your local mall - they wouldn't expect to have their CC cloned in a shop, so they don't think it will happen on line.

    It is up to those of us that have the way withal to make electronic 'life' as secure as we can - we should have a fair grasp of what can be sublimated and we need to protect the general user as much as we can.

  11. Tom Kelsall
    WTF?

    Will someone please correct my understanding? Because it's clearly wrong.

    As I was given to understand, the Root Certificate upon which all an organisation's issued certificates are based is generated on a machine which is not connected to the network; and may even be switched off until needed? If this were the case, surely breaking into the CA's connected servers will only allow you to HARVEST, and NOT to permanently compromise the creation process?

    If my understanding is correct, then revoking the single root certificate would also revoke anything based on it?

    So as I said - my understanding is clearly wrong... will someone put me right please?

  12. Anonymous Coward
    Anonymous Coward

    @Tom Kelsall

    The root CA is used to sign all the certificates it creates, which should be either issuing CAs or policy CAs. The root CA should be offline (either isolated network, or off) with the private key in an HSM. If a policy CA is created that too should be offline and issue certifcates for issing CAs, with its key in a HSM.

    The issuing CA should if possible have its private key in an HMS and all the private keys it generates encrypted, and are archived, with recovery certificates, which again should be stored in a secure location.

    Each CA signs all of its issued certificates with its own private key, with information linking to its parents (issuers) CRL, so it can check if its been revoked. The public key for the CA contains its CRLs to allow you to check if its been revoked. The root CA has no CRL, as nothing issued it, it was self signed, so if that is gone you have to rip out the trust for that root CA.

    If a CA is compromised, then depending on how it was setup, was the root available, were all certs issued from the root, are they creating certs using an issuing CA that its cert was issued by another CA, which only allowed them to issue none CA certs, thus not allowing then to create a 2 tier system, then, their 'root' is compromised. Due to the way CRLs work and some systems implement the checking, it could take months for it to be considered revoked, as the CRL has a life, and within that period, it doesnt have to check for a update. so the quickest way to update it is either clear the cache or rip out the trust. Then their is the general trust, they have been compromised, do you still trust them.

This topic is closed for new posts.

Other stories you might like