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

 



Forgot your password?
typodupeerror
×
Networking Security The Internet IT

Ask Slashdot: Does SSL Validation Matter? 243

An anonymous reader writes "Right now, in an email list excluded from the public eye, some bright people are discussing the future of SSL. Under debate is (a) do they allow DV (domain only validation) certificates to continue to exist (exist for e-commerce use? only encryption use?) or do they require a higher degree of certificate validation? (b) Do they allow certificates to be issued with non-unique common names (certificates used on internal networks, think your exchange server) or do they ban the practice? If this were 'hypothetically' a heated debate going on right now and you could chime in, what would you say?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Does SSL Validation Matter?

Comments Filter:
  • by TheLink ( 130905 ) on Saturday August 06, 2011 @02:48PM (#37009172) Journal
    From my cynical POV, the industry is all about money and little to do with security. From the browser makers to the CAs.

    The browsers by default won't warn you if say your US bank's server cert is one day signed by CNNIC (China) while you're in China. Or vice versa.

    The CAs (Verisign, Comodo etc) have been known to sign certs that they shouldn't. And the browser makers don't kick those who repeatedly screw up.
  • Cost is too high (Score:5, Interesting)

    by karl.auerbach ( 157250 ) on Saturday August 06, 2011 @03:39PM (#37009592) Homepage

    The barrier to entry for a cert authority to be recognized by browsers is too high, as a consequence the price for certificates is too high - it is based on near-monopoly conditions.

  • by Animats ( 122034 ) on Saturday August 06, 2011 @03:44PM (#37009614) Homepage

    The CA/Browser forum (which is dominated by certificate authorities) is proposing to make changes in the way EV certificates are issued. The changes weaken EV certs.

    Existing EV cert policy is that EV certs MUST contain the organization name, its business name and address, and its jurisdiction of incorporation. [cabforum.org] In the proposed draft [cabforum.org], (p. 13) "Organization name is OPTIONAL".

    This essentially makes EV certificates meaningless. The whole point of an EV certificate is to unambiguously identify the business owning the certificate. So if you need to sue, file criminal charges, or send in a collection agency, you know where to send the process server, cops, or collection agents.

    (At SiteTruth, our system considers SSL certificates without a business name and address to have no value in establishing the legitimacy of a company. We've always done this for "domain controlled only" certs, and will now do it for EV certs missing a business name or address.)

  • by Onymous Coward ( 97719 ) on Saturday August 06, 2011 @03:51PM (#37009674) Homepage

    I've been using the following to help me validate certificates:

    http://perspectives-project.org/ [perspectives-project.org]

    They have a bunch of systems that monitor SSL certs for changes. They call them "notaries". You can run a notary, too.

    It helps to make sure the cert you're seeing is what everyone else is seeing and no one is doing a man-in-the-middle attack on you.

  • by fyngyrz ( 762201 ) on Saturday August 06, 2011 @04:39PM (#37009970) Homepage Journal

    1) Stop selling the idea that certificates "verify" who you're talking to. They don't. They never did. As soon as I compromise your server -- easily done, as history shows -- I have your certificate. If it is remote across your network, a little more work, but still, soon I'll have it. Now you have still encryption of the intermediate channel, but the wrong person is catching the data.

    2) Tell the truth for once, and let people know that certificates provide encryption of the intermediate channel, hardening ONLY that channel against interception (but NOT proofing it.) ID is NOT provided, only an invalid assumption of ID built out of the lies of Verisign and its co-scammers.

    3) Stop "allowing" certificates at all. We can easily make them at zero cost, and we should. The whole "Verisign" thing is a complete and utter scam, and always has been, one with the collusion of the browser makers with the fake warnings and "scare the user" policies. Giving ownership of the encrypted data channel to profit making operations was a stupid, stupid move, and has served only to cripple e-commerce from the day it began -- it's one more useless and endless cost for the small entrepreneur to have to absorb, and therefore in the end, the consumer. Further, it has evolved into a higher stakes / cost game of buying that little green verification bar in some browsers. Scams upon scams.

    ...but of course, this will never be fixed, because the whole "that's who you're talking to" scam is big, big money (extorted from merchants and others who want to provide encryption to the general public), and big money wins out over reality every bloody time.

    Doesn't matter how "smart" the people are working on this. They'll go with the money.

  • by d3vi1 ( 710592 ) on Saturday August 06, 2011 @05:25PM (#37010222)
    As you pointed out, it's not a fault of TLS as a protocol. TLS is a decent protocol, but the trusted roots part is not the best approach. I really have much better trust in DNSSEC as an approach. I just wish there was a generic way of publishing all keys over DNS (instead of LDAP) for SSH, PGP, S/MIME, SSL and anything else.

You knew the job was dangerous when you took it, Fred. -- Superchicken

Working...