Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
The Internet Communications Encryption Security IT Your Rights Online

EFF Asks Verizon Whether Etisalat Deserves CA Trust 135

Peter Eckersley writes "Today EFF published an open letter to Verizon, calling for investigation of a trusted SSL Certificate Authority. Etisalat is a majority state-owned telecom of the United Arab Emirates with operations throughout the Middle East. You may remember that last year Etisalat installed malware on its subscribers' BlackBerry phones, and was recently pivotal in the UAE's threat to disconnect BlackBerry devices altogether if Research In Motion did not provide a backdoor for BES servers' crypto. This company, which appears to be institutionally hostile to the existence and use of secure cryptosystems, is in possession of a master certificate for HTTPS, encrypted POP and IMAP, and other SSL-based security systems. Etisalat's CA certificate is not trusted directly by Mozilla and Microsoft, but was instead delegated as an Intermediate CA by Verizon. As a result, we are asking Verizon to investigate whether it is appropriate for Etisalat to continue holding this certificate, and to consider revoking it."
This discussion has been archived. No new comments can be posted.

EFF Asks Verizon Whether Etisalat Deserves CA Trust

Comments Filter:
  • Well duh (Score:4, Interesting)

    by Pharmboy ( 216950 ) on Saturday August 14, 2010 @08:21AM (#33250088) Journal

    Again, well duh. Is there really any question that they can't be trusted with granting certs when they are so openly hostile to encryption of any kind?

    • Re: (Score:2, Insightful)

      by mysidia ( 191772 )

      If you think Etisalat is untrustworthy... keep in mind you too can have your very own privately branded CA through GeoTrust [], Global Trust's Root Signing service, or QuoVadis / RSA's Root Signing Service.

      You just have to meet their minimum financial net-worth and insurance requirements, policy requirements, and "compliance" guidelines.

      The limiting factor is the cost of these services. If you are willing to pay enough, you can have your own CA.

      The fact of the matter is, trust is not part of the equ

  • Revoke time (Score:4, Insightful)

    by ewanm89 ( 1052822 ) on Saturday August 14, 2010 @08:22AM (#33250096) Homepage
    Time to revoke Verizon certificates on my computers.
    • by Xugumad ( 39311 )

      I've been trying to find these certificates to remove them. They don't appear to be anywhere on Ubuntu (probably for the best)... is that just me, or are they hiding under a strange name?

      • Re:Revoke time (Score:4, Interesting)

        by TheLink ( 130905 ) on Saturday August 14, 2010 @11:42AM (#33250914) Journal
        Verizon owns Cybertrust whose CA cert is installed in Mozilla Firefox.

        From the article:
        "We are writing to request that Verizon investigate the security and privacy implications of the SSL CA certificate (serial number 0x40003f1) that Cybertrust (now a division of Verizon) issued to Etisalat on the 19th of December, 2005, and evaluate whether this certificate should be revoked."

        FWIW, CNNIC (state network information center of China) has it's cert signed by Entrust. So if you don't trust CNNIC, you shouldn't trust Entrust either :).

        You can use the Certificate Patrol plugin to help keep track of CA/cert changes in sites you visit. After all if your bank website's cert was signed by Comodo today, but CNNIC when you go to China, I'd think you'd want a warning. Current browsers by default would NOT give you a warning in this scenario as long as the website's certificate chain is ultimately signed by one of the CA certs installed in your browser.

        So go figure how much the browser bunch really care about your security.
      • Re:Revoke time (Score:5, Interesting)

        by VortexCortex ( 1117377 ) <(VortexCortex) ( ...> on Saturday August 14, 2010 @11:43AM (#33250916)

        If you use firefox: Edit > Preferences > Advanced > Encryption > View Certificates > Authorities

        Personally, I've deleted all of the authorities and only add certificates as I need them.

        This is because a CA can be compelled by the country they are in to sign a certificate for any domain.
        For example: If your browser trusts the Etisalat CA then Etisalat can can create a SSL certificate for even though didn't ask for one.
        If your DNS then points to a Etisalat server it can serve pages as (pretty green "I'm secure" bar and all).

        You'd have to view the cert info to make sure Google's real CA signed the current cert...
        Thawte, Verisign and Verison can be compelled by the US to create fake certs too, but in this case only the IP address would tip you off.

        If my browser was sent a fake cert and fake DNS results I will be presented with an "Untrusted Certificate" screen.
        Since this normally only happens when Google's cert is about to expire I would be alerted.

        tl;dr: CA system is broke because any CA can make a cert for your domain without your consent.

        • In part, this problem might be solved by DNSSEC.

          • Re:Revoke time (Score:5, Insightful)

            by bertok ( 226922 ) on Saturday August 14, 2010 @06:21PM (#33253110)

            In part, this problem might be solved by DNSSEC.

            Unfortunately not, because the decision makers of internet security protocols are all greedy pigs who want to charge you money for a service that you can do yourself for free.

            From day 1, the HTTPS CA and DNS CA systems should have been one and the same.

            That is, not tying the two systems together is a gaping security hole that means that even if you control a domain, someone else can issue certificates for that domain and the users can't tell.

            DNS should have had a CA hierarchy built into it from the beginning, so that if you own '', you can issue a cert for it for free as easily as creating a record, and if anyone else tries to do the same, they won't get very far because they can't create a cert signed by *your* DNS domain key.

            There's so much more money to be made however by taking the CA control out of the hands of the DNS domain admins and putting it in the hands of some corporation.

            • I agree 100% regarding SSL CAs should have been based on a DNS hierarchy.

              But there is nothing to stop that from occurring, now that the root is signed, dot-gov, dot-edu, dot-org, dot-biz, dot-us, and may other ccTLDs are signed and available for the domain owners to add their DS keys into the zone to establish a chain of trust from the root all the way down. Dot-com and dot-net are soon to follow in the next year.

              What is missing right now is extending that trust model all the way down to the stub-resolvers

  • Just state the criteria. (I considered putting funds into ethical stock once, but the restrictions seemed dumb, both in terms of what they considered ethical (not in my opinion) and vice versa. In the end I chose them myself.)

  • Blocked (Score:1, Interesting)

    by Anonymous Coward

    The NY Times story is being blocked by their proxy servers. Trying to keep costumers in the dark as usual.

    • Re: (Score:2, Funny)

      by fbjon ( 692006 )

      Trying to keep costumers in the dark as usual.

      Yes, how will the wardrobe purveyors follow this news thread now??

  • by simpz ( 978228 ) on Saturday August 14, 2010 @09:00AM (#33250222)
    A dodgy trusted SSL authority could trivialise man in the middle attacks (especially with state backing). Can any SSL client apps (Thunderbird/Evolution/Firefox etc) be told to remember an SSL cert for a site and be told to report if it changes? Like how SSH does with it's keys.

    It obviously will change when it expires but at least you could examine it ( a really smart client could tell you that just the dates have changed).

    Then if a valid new cert was put in place between yourself and the actual site you'd see the change.
      • by simpz ( 978228 )
        Looks good. I wonder if it can be hybridized so that I can at least get some reassurance from the CA about any new SSL sites I visit (if they feel they are valid) before I accept them.
      • by tepples ( 727027 )
        From "Life without a CA":

        How do you validate the certificate? It depends on the other end. For sites I worry about, like my bank or favorite shopping stores, I call support and ask for the SSL fingerprint and serial number. Sometimes the support person even knows what I'm talking about. I suspect they just open their browser, click on the lock icon and read me the information.

        But if the business isn't yet a household name, how would you even see the telephone support number without accepting the certificate? And what do you do about businesses whose telephone hours "conveniently" coincide with the hours when you're supposed to be at work or, especially in the case of overseas businesses, with your ordinary bedtime?

        • Well, perhaps people need to reevaluated the risks involved with giving credit card numbers to small, unknown businesses that they cannot find any information about except online.
          • by tepples ( 727027 )

            Without a TLS certificate from a well-known CA, how do you recommend that a new small business take money from customers? My employer used to use PayPal, but PayPal cut him off after some Indonesians started using a bunch of stolen credit cards on the web site. It appears PayPal has cut off a bunch of other companies too [].

            And how do you recommend that someone securely authenticate to a non-commercial site, such as a blog, forum, or wiki, without a CA and without sending his account's username and password

            • For a small business, there is always the option of making sales the old-fashioned way: in person. Perhaps that would be a good place to verify a fingerprint. It would also help people avoid scams, since the scammers would have to meet their victims in person.

              As for blogs, forums, and wikis...well, if MITM attacks are a serious concern, then perhaps people should take the time to find the fingerprints for the keys. Maybe even build a web of trust model.

              Look, I am not a fool, and I don't actually t
              • For a small business, there is always the option of making sales the old-fashioned way: in person.

                The business was a click-and-mortar retailer. Click brought in several times more revenue (and earnings) than mortar ever did because our order filling system was so much more efficient than competitors'. If we dealt only with customers living within 30 miles or 50 km of our warehouse and retail store, we likely wouldn't be able to pay rent, utilities, and other overhead. Another comparison: imagine if a publisher of mass-market software decided to sell copies of its software only on disc, and then only to

                • I've read about OpenPGP's web of trust, but how can this work without frequent air travel to get a key signed by people living in different parts of the world?

                  Well part of the idea behind the web of trust is that you can derive trust from others who travel. So, for example, you might obtain my certificate, and it was already signed by 3 people whose fingerprints you verified; then you have some assurance that my key is authentic. Since there is a chance that people are conspiring against you, you might limit this to be 1- or 2-deep, so that you don't wind up with too long of a WoT chain. You can also have different levels of trustworthiness; perhaps you requ

  • by davidwr ( 791652 ) on Saturday August 14, 2010 @09:13AM (#33250256) Homepage Journal

    Browsers need to clearly show WHO is authenticating and some measure of "reputation" of each authenticator in the chain.

    Let's use [] as an example.

    Its certificate is issued by "Thawte SGC CA" which in turn is issued by "Verizon, Inc."

    If the "reputation" of Thawte and Verizon were both high, then the lock-symbol in my browser would be green. If either one were "medium" then it would be "orange." If either one had a bad "reputation" then it would be red. Of course if any link in the chain were revoked then there should be no lock-symbol at all and possibly some big nasty warning messages to boot.

    Browsers also need to allow users to remember signatures alert users if they change, to identify poisoning attacks where FakeBank gets a valid, seemingly-reputable certificate for due to a clerical error or fraud AND uses it along with DNS poisoning or other means to fool your bank into visiting FakeBank.IP.Address and getting a "valid" certificate when it wants to go to

    Whether it's the browser vendor that determines who the reputation vendor is or whether it's the user will largely be a market decision, at least in most countries. In some countries of course the government will try to control reputation, labeling any certificate authority that doesn't follow its rules as "untrusted."

    In the case of Etisalat, reputation vendors in the West may mark Verizon as "green" and Etisalat as "orange" or even "red." The UAE may try to force people in its country to use a reputation authority that marks Etisalat as "green" and COMODO CA Limited, the authority the EFF uses, as "red" in retaliation for bringing this up in the first place. Memo to the UAE if they try this: "Good luck with that."

    • Maybe that is best word. CA only certify WHO somebody is. They do not certify what they are doing is correct.

      By the way, you can alrady look at the certificate and see the chain of trust.

      Looking for details the first secure link of [] etisat does not use their own CA. funny?

      Revoke that certificate manully? once a certificate is revoked you no longer can look at it due to the interface works. Not really a bug, untill you encounter it.

      • By the way, you can alrady look at the certificate and see the chain of trust.

        Yes, I know. The browser needs to be able to interpret this and display an "layman-use" symbol that indicates trust.

        Most browser's current "layman-use trust symbols" are either "signed," "not signed," "partially signed," "signature revoked," or similar. There is no


        indication of the trustworthiness of the signature, even though the industry trains people to "look for the lock" and equate that lock with trustworthiness.

        Whether this is a user-education issue, where the industry has been telling people the

      • Yes they do. Their CA is entitled "ComTrust".

    • Browsers need to clearly show WHO is authenticating and some measure of "reputation" of each authenticator in the chain.

      Who guards the guards?

      Who gets to say who is reputable - and - just as importantly - why should I believe them?

  • by Bob9113 ( 14996 ) on Saturday August 14, 2010 @09:39AM (#33250344) Homepage

    Looking blearily through pre-coffee eyes at my computer screen, I briefly thought I had awoken ten years in the future.

    "Today EFF published an open letter to Verizon, calling for investigation...

    HOLY CRAP! I must have been asleep for years! The whole Google/Verizon/FCC thing must have tipped us over. We must have slid into open fascism while I was asleep, if even the EFF has stopped suggesting that the government perform investigations and has started bowing and scraping before Verizon.

    You maniacs! You blew it up! Damn you. God damn you all to hell!...

    ...Oh -- it's just about a CA.

  • by TuballoyThunder ( 534063 ) on Saturday August 14, 2010 @09:40AM (#33250346)
    There are so many trusted certificate signing authorities that I believe the trust system is untrustworthy. I counted over 40 certificate authorities in Mozilla and I did not make it past the letter "I' in the list of trusted CA's. Throw in the intermediate CA's and the problem gets worse. Lets assume that all CA's are trustworthy. Furthermore, assume that there is a 1 in a million chance for any individual CA in any given year to make a mistake. A system of 100 CA's would have a 1 in 10,000 chance of making a mistake. Many of the CA are regionally focused and it makes no sense why a user should trust all CA's equally.

    The following changes could be useful:

    • selectively prune the trust hierarchy
    • flag certificates that change (there are addons)
    • specify the maximum path length you are willing to trust
    • Be able to assign a trust weight to a CA
    • Re: (Score:2, Informative)

      by davidwr ( 791652 )

      * selectively prune the trust hierarchy

      - Not practical without creating an artificial scarcity problem. You want enough trusters to meet market demand and prevent artificially high pricing.

      * flag certificates that change (there are addons)

      - Very good idea.

      * specify the maximum path length you are willing to trust

      - I'm not sure this is explicitly needed with trust weight assignments. You can assign a weight of "x-1" for each level you drop, and give 1st- and any-other-level certs whatever weight you want - "2" for signers you trust to delegate but don't trust their assignees to delegate, "infinity" for authorities you trust won't ever make a mistake

  • by X.25 ( 255792 )

    I have had a hard time explaining to people why self-signed certificates are much more secure than "trusted" certificates issues by likes of Verisign, Thawte, etc.

    They still don't understand it :)

    • I have a hard time with this. I am operating a web site which provides information to identified users. I have a self-signed certificate which correctly identifies itself as belonging to my site. What is wrong with this? I want you to identify yourself to me, securely, before I will tell you anything.

      In another scenario, someone is using a shared certificate issued by a "trusted" supplier, but owing to the domain structure it could be cloned and used in a MiM attack. My browser doesn't care.

      My conclusion fr

      • by Dr. Evil ( 3501 )

        How do you revoke a self-signed cert?

      • by jon3k ( 691256 )
        Wow, where to start. The point of a trusted CA is you have a 3rd party who can give you the thumbs up or thumbs down on a resource. You seem to work from the assumption that you intrinsically trust the site you're trying to reach. The point of a CA is to verify that you are indeed talking to who you think you're talking to, and to encrypt that communication. If I'm on the Internet and I click a link to and I get an unsigned SSL certificate warning you're saying I should
        • by Dr. Evil ( 3501 )

          Aside from the problem of revoking a self-signed cert, I agree with this self-signed philosophy.

          The trick is that you need to find a way to bootstrap the trust. That will probably be an out-of-band communication, e.g., a letter, phonecall, visit to an office or something. But once you've established that trust, then you are not depending on multiple third parties, some politically hostile, to ensure that your communications are secure.

          For out of band communication, putting a fingerprint of a signature

        • I'm saying that nowadays with hosting services sharing certificates among multiple subdomains, you should not trust a signed SSL certificate that is not for that exact domain any more than you should trust a self-signed certificate. It should be important that the certificate be for the exact domain being accessed, but currently it isn't, for commercial rather than security reasons.

          Incidentally, "Wow, where to start" is not an argument.

      • I have a hard time with this. I am operating a web site which provides information to identified users. I have a self-signed certificate which correctly identifies itself as belonging to my site. What is wrong with this?
        Now someone please explain why I'm wrong.

        As a user, how do I tell that the self-signed cert that I received for your site came from you and not from a MITM between you and I? It is a trivial task to set up a rogue "free wifi!" AP that proxies all connections.

        • by Burz ( 138833 )

          As a user, how do I tell that the self-signed cert that I received for your site came from you and not from a MITM between you and I? It is a trivial task to set up a rogue "free wifi!" AP that proxies all connections.

          1. Never use "free Wifi" without a VPN connection. This is a good general rule.

          2. Sites using self-signed certs should publish their cert's fingerprint 'out of band'. This means you can view the fingerprint on some (preferably separate) web site, or a telephone conversation, or on some printed correspondence. Then access the https: site and when the cert dialog appears, tell it to view it so you can see the fingerprint and compare it with the out-of-band version.

    • A self-signed certificate isn't as trustworthy as you think. In particular, it's vulnerable to a man-in-the-middle attack on any computer for which it has not been previously installed.

      Scenario: is getting some local buzz for its new online store. They use self-signed keys but most of their customers don't do any manual checking to authenticate the key.

      I'm a rogue operator for localisp and I know it will be featured in the paper tomorrow along with its web site and I know the newspaper wil

  • Is there a way I can get a revocation certificate for Etisalat now, and install it now, and not have to wait for Verizon to do something about it?

At work, the authority of a person is inversely proportional to the number of pens that person is carrying.