Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

What Would It Take To Have Open CA Authorities?

Posted by ScuttleMonkey on Fri Jul 18, 2008 03:06 PM
from the sounds-like-vc-pitch-time dept.
trainman writes "With the release of Firefox 3, those who have been using self-signed certificates for SSL now face a huge issue — the big, scary warning FF3 issues which is very unintuitive for non-technical users. It seems Firefox is pushing more websites in to the monopolistic arms of companies such as Verisign. For smaller, especially non-profit groups, which will never have issues with domain typo scammers, this adds an extra and difficult-to-swallow cost. Does a service such as this need the same level of scrutiny and cost since all that is being done is verifying domain and certificate match? This extra hand holding adds a tremendous cost and allows monopolistic companies such as Verisign to thrive. Can organizations such as Mozilla not move towards a model that helps break this monopoly, helping establish a CA root authority that's cheap (free?) and only links the certificate to the domain, not actual verification of who owns the domain?"
+ -
story

Related Stories

[+] Technology: VeriSign Jacks Up .com, .net Prices To the Max 215 comments
se7en writes "VeriSign is jacking up prices for the .com and .net domains for the second year running, increasing both by the maximum 7% allowed under its exclusive contract with ICANN. 'Assuming that VeriSign continues the 7 percent rise each year (which seems reasonable given the company's history), registrars will be looking at $9.00 for .com domains by the time the current contract ends in 2012 — a 50 percent increase in six years.' Registrars have no choice but to pony up, and chances are they'll pass the pain on to customers."
[+] Your Rights Online: VeriSign Granted a Patent Covering SiteFinder 85 comments
An anonymous reader writes "Remember VeriSign's SiteFinder? Turns out that a couple of months back VeriSign was granted a patent on resolving unregistered domains. This came about thanks to its acquisition of eNic, operator of the .CC Domain. How long before Verizon, Earthlink, and OpenDNS are hit up for licensing fees?"
[+] IT: When Is a Self-Signed SSL Certificate Acceptable? 627 comments
UltraLoser writes "When is it acceptable to encourage users to accept a self-signed SSL cert? Recently the staff of a certain Web site turned on optional SSL with a self-signed and domain-mismatched certificate for its users and encourages them to add an exception for this certificate. Their defense is that it is just as secure as one signed by a commercial CA; and because their site exists for the distribution of copyrighted material the staff do not want to have their personal information in the hands of a CA. In their situation is it acceptable to encourage users to trust this certificate or is this giving users a false sense of security?"
[+] Technology: Mozilla SSL Policy Considered Bad For the Web 897 comments
Chandon Seldon writes "The issue of digital certificates for SSL and the policies surrounding them comes up repeatedly. I've written an article criticizing the behavior in Firefox 3, which includes a serious comparison of the current Mozilla policy — restricting encrypted HTTP to paying customers — to a violation of net neutrality."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • CACert (Score:5, Informative)

    by Anonymous Coward on Friday July 18 2008, @03:09PM (#24246121)

    try it....

    • Re:CACert (Score:5, Informative)

      by zerOnIne (128186) on Friday July 18 2008, @03:12PM (#24246163) Homepage

      Seconded. go here [cacert.org].

        • Re:CACert (Score:5, Informative)

          by theodicey (662941) on Friday July 18 2008, @03:56PM (#24246831)

          StartCom [startssl.com] is free and already supported by Firefox.

          Mozilla just wants CAs to offer some level of accountability and identity verification. Their CA certificate policy [mozilla.org] is explicit in its requirements.

          I don't see the point in having Verisign certificates eveywhere, but I also don't see why you should blindly trust a Robot Certificate Authority like CACert, without further assurances.

          • Re:CACert (Score:5, Insightful)

            by cbreaker (561297) on Friday July 18 2008, @03:45PM (#24246653) Journal

            Verisign and friends aren't much better. They have given SSL certs to all kinds of scammer or ridicuous domain names in the past, and continue to do so.

            Trusting that companies like Verisign are doing the right thing is no better than doing nothing.

          • Re:CACert (Score:5, Insightful)

            by Anonymous Coward on Friday July 18 2008, @04:01PM (#24246935)

            Given the general security principle, espoused by most web browser makers, of "Trust nobody unless it's a secure connection, and even then be careful"...

            Actually, the principle espoused by most web browser makers seems to be "Trust anybody if your connection is unencrypted, but if you wish to encrypt your traffic, trust no-one unless they've given a wad of cash to a CA."

            It seems to me that a user using an unencrypted connection to an unidentifiable web site (that is to say, all http web sites) should receive even more warnings than a user using an encrypted connection to an unidentifiable web site. But somehow, that's not the case.

            This Firefox scaremongering isn't just driving people into the arms of Verisign, it's also driving webmasters away from using encryption, even where web forms might be involved. Too bad - encryption is a good thing.

              • Re:CACert (Score:5, Insightful)

                by tha_mink (518151) on Friday July 18 2008, @04:05PM (#24246997)

                Have you ever applied for an SSL certificate? It's a PITA, because you do have to provide the issuer with a load of documentation (usually comprising of some legal documents such as your employer's charter et al, plus evidence you do, actually, work for them) to confirm you're who you say you are.

                What are you talking about? I buy SSL certificates ALL THE TIME, and it couldn't be easier. It's easier than buying the domain name. It's automatic and happens in seconds these days. I have no idea where you get your certs from but yo, you don't seem like you know what the hell you're talking about.

              • Re:CACert (Score:5, Insightful)

                by Evets (629327) on Friday July 18 2008, @04:08PM (#24247037) Homepage Journal

                A chain is only as strong as it's weakest link. Verisign can require all the verification they want, but there are other "trusted" root CAs that don't.

                I purchased an SSL cert, and because my spam software rejected the provider's messages (with good reason), they had to send my ssl cert to a throwaway address I set up. There was nothing in the way of identification verification.

                Regardless of whether or not this was a "one-time" instance, once again we have people trusting big providers simply because they are big providers. A revenue stream does not make you secure.

                There is no difference between a free cert, a $25 cert, and a $500 cert - other than the fact that no free cert providers have trusted root CAs by default. Nobody actually reads the certificates, the only time an end user ever cares about cert's it is because a dialog popped up that gave them a warning, and half the time with a warning, the end user simply clicks on through anyways.

                People should see SSL certs for what they are - end point-to-end point encryption mechanisms and nothing more. Thinking they are anything more is simply a false sense of security.

  • Not the first one... (Score:5, Interesting)

    by bradgoodman (964302) on Friday July 18 2008, @03:13PM (#24246177) Homepage
    I have been using PayPal for many years for automatic payment processing on my web site for shareware I sell.

    When Google Checkout came along, I figured I'd accept that too - so I started doing scripts on my web site to take Google Checkout payments.

    This came to a screeching halt when I realized that Google Checkout payments (or at least automated CGI processing of them) would only be done through web sites with SSL certificates signed by one of the "Major Authorities".

    I wasn't willing to shell out $100 (about half my yearly profit!) for the stupid certificate.

    This FF3 problem is even worse - if you use SSL, your web browser would be screaming to your end-users that you're probably dealing with some hokey-untrusted individual!

    Let's just say that in any respect, I won't be having any little buttons on my site recommending that people use Firefox...

  • I run a small norwegian forum, and we use SSL. Since our income is around 100USD a year, which is donated by members, it would be very unfair to spend all of that on a SSL cert. However, how can one explain that there is no security risk involved in creating an exception when the browser so fiercly states that it is a huge security risk? It would be better if you just got a warning like "This site is probably not your bank"...
  • No (Score:5, Insightful)

    by squiggleslash (241428) on Friday July 18 2008, @03:17PM (#24246225) Homepage Journal

    One entire point of SSL is to ensure that the user can trust the site they're connecting to. If I register citicardbank.com, my inability to get an SSL certificate for it without being traced by my phishing victims severely undermines my ability to rip people off.

    The only way to get what you're asking for is to get a secondary protocol, somewhere between HTTP and HTTPS, that would provide privacy for the communication link but wouldn't promote the notion that the end domain is what it says it is. Whether such a thing is a good idea is open to question, even if it is desirable.

    If push comes to shove, the only problem with the present regime is that it's expensive. There's increasing amounts of competition in that space, so you should expect prices to come down over time. Wait. .com domain names once cost more than what many SSL certs do today.

      • Re:No (Score:5, Insightful)

        by squiggleslash (241428) on Friday July 18 2008, @03:35PM (#24246483) Homepage Journal

        First of all, that's not in any way, shape, or form, a counterpoint.

        Are you using different top level domains for all your systems? Because if you're not, you should be able to make do with a wildcard SSL certificate, which generally runs to a few hundred dollars per year, not $1,000. Just saying.

        In any case, your particular set of circumstances means you have control over who would need the self-signed certificates. In particular, you can legitimately create a CA of your own and import it's certificate into the web browsers of your users, because that CA (you) is accountable to you and your users.

        This is very different from someone outside of the organization trying to get "secure access" to your systems, not knowing for sure that they really are connecting to you (and not a typosquatter.)

  • Monopoly? (Score:5, Informative)

    by nonpareility (822891) on Friday July 18 2008, @03:19PM (#24246245)
    The fact that there are "compan*ies* such as Verisign" means Verisign is not a monopoly. In Firefox, go to Tools, Options, Advanced, Encryption, View Certificates, Authorities. These are all valid CAs according to Firefox. As for being cheap, a quick check at GoDaddy's says you can get one from them for $30/year.
  • Secure DNS can help (Score:5, Informative)

    by John.P.Jones (601028) on Friday July 18 2008, @03:25PM (#24246329)

    Can organizations such as Mozilla not move towards a model that helps break this monopoly, helping establish a CA root authority that's cheap (free?) and only links the certificate to the domain, not actual verification of who owns the domain?

    How can anyone possibly establish that a given certificate is associated with a given domain without first proving that they do indeed have the (ownership) rights to establish said association?

    What you are asking for can be accomplished via SecureDNS, you can enter the hash of the certificate in the DNS entry and Secure DNS ensures that only the authorized party can enter that association and verifies that it was not changed. SecureDNS facilitates a lot of these kinds of authentication issues by extending the rooted hierarchy of DNS names to securely dissiminate information, whether it be IP addresses of servers or public key commitments. See my paper "Layering Public Key Distribution Over Secure DNS using Authenticated Delegation" (ACSAC 2005).

  • by davidwr (791652) on Friday July 18 2008, @03:30PM (#24246409) Homepage Journal

    The certification authorities really need to get together with the web browser vendors so the big scary warnings can be made trust-level-appropriate.

    For example:

    Domain confirmed: [green][yellow][red]
    Responsible Party Identity Confirmed: [green with seal][green][yellow][red]

    Where "yellow" meant unconfirmed or self-signed and not whitelisted SSL or an easy-to-fake or -steal ID such as a credit card, "red" meant revoked, expired, or invalid credential, and "green" meant a valid SSL or hard-to-fake or -steal personal ID such as a driver's license backed by a notary. "Green with seal" meant a financially-backed guarantee, something big banks would probably get.

    Most small-time web sites would be either green/yellow or yellow/yellow, depending on if they had self-signed certificates.

    The cost of a "no identity confirmed" green/red certificate shouldn't be much more than domain registration. A "yellow/red" self-signed certificate would remain free.

    If people expect "green with seal" when dealing with major financial companies, "green" with most businesses, and "yellow" for personal web sites, they'll give the appropriate level of trust.

  • by petard (117521) on Friday July 18 2008, @03:33PM (#24246455) Homepage

    They offer certs with domain validation for free. There are gentle attempts to upsell you to higher levels of validation, but their domain validated certificates work without errors. Look here [startssl.com].

    If you want certs that are validated to your business' identity (instead of just your domain) and don't indicate in the DN that they were free, there is a small charge.

  • by Doc Ruby (173196) on Friday July 18 2008, @03:38PM (#24246557) Homepage Journal

    Instead of relying on centralized CAs, and implicitly trusting these privileged monopolies, we could shift to trust webs [wikipedia.org].

    It's like a social network. You trust who your "friends" trust, and distrust who they don't. With weightings, so some friends' and enemies' associations (and dissociations) count more than others Because some people you trust in their content, but not their judgement of who to trust (and vice versa, but probably more rarely).

    Trust webs can perfectly simulate the current centralized trust model. You can just set your trust web to always trust whoever, say, VeriSign trusts, and ignore everyone else, which is what we get by default today. But you could tweak your trust web to say "If my grad student distrusts a site, then ignore whether VeriSign trusts it".

    Such a trust web could therefore just ship set up with the current CAs the only trusted authorities, and work exactly the same as now. But we'd each have the freedom (or our sysadmins, who could lock the trust web changes away from normal users) to emphasize whoever we actually trust to influence our automated trust.

    Independent authorities could "watch the watchers". So investigators with a reliable track record could become important "second guessers" to the "offical" CAs. People could make their reputation by proving a trusted authority has less than 100% good judgement. And the whole system can become more robust, instead of fracturing as soon as different CAs have different trust levels for different sites.

    The technique and some SW is already available, for apps like PGP and others that rely on a Public Key Infrastructure. What's necessary for the critical mass that makes such a system work is for a browser like Firefox to upgrade to a trust web, with an easy and reliable UI with sensible defaults. Then we're as strong as the trust network in which we embed ourselves.

  • by Illbay (700081) on Friday July 18 2008, @03:41PM (#24246603) Journal

    The O.P. mentions "...monopolistic arms of companies such as Verisign."

    Okay, look. The word "monopoly" has as its prefix the stem "mono-," from the Greek, meaning "one." That means there can only be ONE "monopoly."

    A phrase such as "monopolistic company LIKE Versign..." is absurd on the face of it. If there are other companies LIKE Verisign, then there is no monopoly.

    Is it REALLY that hard to understand?

    This is an example of how the rising generation is so used to "buzz words" chosen for shock value, etc., and has gone completely away from clarity of speech and writing. What the O.P. means to say, really, is "I don't want to pay the going rate for this service, so I'll call Verisign 'a monopolistic company' because everyone knows 'monopolies' are bad, and that will communicate the 'badness' of 'companies like Verisign.'"

    Oddly, the word "rhetoric," also from the Greek (rheteros, "a speech") used to be a positive appellation for the study of good, clear communication of thoughts and ideas. But it has also succumbed to the buzz-word dementia, and now usually means "empty words."

    How sad.

    • by Rakishi (759894) on Friday July 18 2008, @03:49PM (#24246721)

      The problem as I understand it is that self-signed certificates are NOT as secure. Specifically a man in the middle attack can easily fake a certificate because your site needs to send the public key to the user in an insecure way (ie: third party intercepts public key, send their own public key, to you they look identical).

      The point of a CA is to prevent this by having a public key come pre-loaded on your machine so there is no possibility of successful interception (ie: the replaced public key would be rejected by the CA).

    • Let's start with a Man-in-the-Middle attack. Attacker finds an unpatched DNS and points www.somebank.com to their proxy that has SSL support. A user connects, thinking it is their bank. It looks like it, because it really is the bank's website that is being displayed, and the URL is correct. The user enters their account login information, because it's a secure site. The proxy, of course, decrypts the inbound user SSL traffic, stores username/password information, re-encrypts using the bank's SSL session and forwards to the bank. The bank never knows it's not the user - it's encrypted, after all, and it is all correct.

      The idea of certificates is to authenticate the connection, make it impossible to someone in the middle to pretend to be the server to the client, and the client to the server. Actually, it would be better to require users to have certificates as well, in many cases, as passwords tend to be too trivial.

      Now, the price of certificates is horrendous. The passport office provides a document as good, or better, than many certificates, but it doesn't cost many hundreds of dollars to obtain a passport. In fact, as digital certificates are essentially the same as a passport with electronic information, it might be better if the passport office issued digital certificates along with physical passports as a combined package. The added cost to them would be practically nil, and the certificates would have a much greater credibility level than those by most corporations, at least for personal certs.