Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Father of SSL Talks Serious Security Turkey

Unknown Lamer posted more than 2 years ago | from the trust-me-i-invented-a-cipher-system dept.

Security 74

coondoggie writes with an excerpt from a Network World article: "SSL/TLS, the protocol that protects security of e-commerce, has taken a beating lately, with news items ranging from the violation of certificate authorities to the discovery of an exploit that beats the protocol itself. But despite the exploit ... and the failures of certificate authorities such as Comodo and DigiNotar that are supposed to authenticate users, the protocol has a lot of life left in it if properly upgraded as it becomes necessary, says Taher Elgamal, CTO of Axway and one of the creators of SSL."

cancel ×

74 comments

Sorry! There are no comments related to the filter you selected.

Who needs SSL? (2, Funny)

Anonymous Coward | more than 2 years ago | (#37682586)

I don't have anything to hide!

Re:Who needs SSL? (1)

dyingtolive (1393037) | more than 2 years ago | (#37682658)

What will you do when not having anything to hide then becomes illegal?

Re:Who needs SSL? (2)

wsxyz (543068) | more than 2 years ago | (#37682954)

I suppose then the fact that you have nothing to hide would be something to hide.

Re:Who needs SSL? (0)

Anonymous Coward | more than 2 years ago | (#37683064)

But then you would be doing nothing wrong and have noth--HEADSPLODE!

Re:Who needs SSL? (1)

davester666 (731373) | more than 2 years ago | (#37685844)

I suppose then the fact that you have nothing to hide would be something to hide.

...and thus, are no longer breaking the law...

Re:Who needs SSL? (1)

justforgetme (1814588) | more than 2 years ago | (#37688002)

unless they find out you are hiding something!

Re:Who needs SSL? (1)

ElmoGonzo (627753) | more than 2 years ago | (#37682688)

Just post those bank account numbers, the routing codes, and a credit card number or 2. They're not worth hiding.

Re:Who needs SSL? (0)

Anonymous Coward | more than 2 years ago | (#37682956)

In a totally expected anti-twist, all of the above are 12345

Re:Who needs SSL? (1)

Canazza (1428553) | more than 2 years ago | (#37683252)

that's the same combination as my luggage!

Re:Who needs SSL? (0)

Anonymous Coward | more than 2 years ago | (#37683496)

CC: 4225-6533-0052-4812
CVC: 935
Expires: 07/2014
Name on card: Stephen Belmont

Re:Who needs SSL? (2)

cos(0) (455098) | more than 2 years ago | (#37683642)

That's not very bright—assuming you're this card's owner, and the info is correct. This info will now come up on a cursory Google search, and if your credit provider learns that you wilfully published this info, they'll close your account because you've violated the cardholder agreement. The law that provides for reimbursement of unauthorized charges does not extend to people shouting their credit card info from the rooftops and expecting a bailout later.

Re:Who needs SSL? (0)

Anonymous Coward | more than 2 years ago | (#37683742)

That is correct. Assuming the information is valid, if discovered, Stephen Belmont no longer has fraud protection on that account and is now liable for all charges. Its even possible to be considered negligent or even complicit with any associated fraud, thereby becoming criminally liable.

I honestly don't want to believe anyone would be so stupid, but given this is slashdot, it certainly seems *very* plausible.

Re:Who needs SSL? (1)

Anonymous Coward | more than 2 years ago | (#37683818)

All I have to do is claim that someone stole my info and anonymously posted it to this site. For all you know, I may not even be the same person that posted it.

Re:Who needs SSL? (1)

Inda (580031) | more than 2 years ago | (#37688020)

The number doesn't pass the LUHN test. Panic over. Move along. Nothing to see here.

Re:Who needs SSL? (1)

igreaterthanu (1942456) | more than 2 years ago | (#37684106)

You could have at least put the effort in to use a valid check number.

Re:Who needs SSL? (1)

icebraining (1313345) | more than 2 years ago | (#37684622)

Actually, that's interesting. I don't have a CC*, and as far as I know there's nothing one can do with my IBAN; direct debits and such have to be authorized Ã-priori with the bank.

Frankly, having only a single set of numbers that anyone can use to debit money from an account seems completely retarded to me. It's like giving your password instead of using OAuth, and bank accounts are still "somewhat" more important than Twitter's, one would think.

* actually, I have many; they're just virtual, have a small limit and expire one month after being issued.

Re:Who needs SSL? (0)

Anonymous Coward | more than 2 years ago | (#37688416)

as far as I know there's nothing one can do with my IBAN

Clarkson now knows that isn't true [bbc.co.uk]

Re:Who needs SSL? (1)

icebraining (1313345) | more than 2 years ago | (#37688704)

That kind of moronic system doesn't work with my bank - I have to explicitly set up the payment with the bank myself - but in any case the "Direct Debit Guarantee" means he can revoke the payment, no questions asked.

Re:Who needs SSL? (0)

Anonymous Coward | more than 2 years ago | (#37682716)

Everybody's Got Something to Hide Except Me and My Monkey

Re:Who needs SSL? (1)

neight108 (974915) | more than 2 years ago | (#37682812)

I don't have anything to hide!

I find it ironic that "Anonymous Coward" has nothing to hide

Re:Who needs SSL? (0)

Anonymous Coward | more than 2 years ago | (#37682970)

I don't have anything to hide!

So you don't mind posting your credit card number here?

Re:Who needs SSL? (0)

Anonymous Coward | more than 2 years ago | (#37683630)

The digits in my CC are all from the set: 0123456789
And my mother's maiden name is from the set: ABCDEÉFGHIJKLMNÑOPQRSTUVWXYZ

Re:Who needs SSL? (1)

justforgetme (1814588) | more than 2 years ago | (#37688018)

Spanish... very interesting ;-)

Re:Who needs SSL? (1)

aepurniet (995777) | more than 2 years ago | (#37683224)

You and Todd Davis of LifeLock seem to share this unpopular opinion.

Re:Who needs SSL? (1)

wierd_w (1375923) | more than 2 years ago | (#37683280)

Didn't the social security administration tell him in no uncertain terms to stop posting his ssn publicly, due to the number of illegal aliens using it for job applications?

It does its job (2)

faldore (221970) | more than 2 years ago | (#37682666)

I am more worried about my ISP packet sniffing my traffic than a black hat.
As long as the SSL is good enough to keep my ISP ignorant, it's good enough for me.

Re:It does its job (0)

Anonymous Coward | more than 2 years ago | (#37683196)

So your ISP gets a cert signed by random crappy browser-trusted cert authority (e.g., run by an intrusive government) for some domain(s) they are interested in monitoring traffic on, and due to the way SSL is implemented in browsers, you have no idea they are sniffing all your traffic to that site.

SSL is broken.

Re:It does its job (1)

dkf (304284) | more than 2 years ago | (#37683838)

So your ISP gets a cert signed by random crappy browser-trusted cert authority (e.g., run by an intrusive government) for some domain(s) they are interested in monitoring traffic on, and due to the way SSL is implemented in browsers, you have no idea they are sniffing all your traffic to that site.

SSL is broken.

But coming up with something more secure that is still practical, that's hard. Not having certificates last indefinitely is a good thing (limits the amount of damage from an undetected theft) as is not forcing the use of the same CA every time. It's just that some CAs should never have been trusted in the first place and some clients are crap at checking whether a certificate is actually good. One isn't a protocol problem but instead a social one (and just requires a few companies to be crushed into paste to rectify) and the other is a quality-of-implementation issue.

You can't achieve perfect security even for all that (what if a blackhat is looking over the shoulder of the legitimate admin when the logs are being browsed? SSL doesn't prevent that! Oh noes!!!) and it's important that at least some people remain vigilant for problems. But you're advocating throwing many babies out with a rather small amount of bathwater, because all the major alternatives are either more vulnerable in general or require practices that will be desperately insecure in the hands of non-experts. The good thing about SSL is that, apart from the issues with trustworthiness of CAs, it deals very well with securing the communications channel without presenting decisions to users that they are unqualified to make; J Random User cannot and will not verify a signature of anything by hand, since just clicking OK is easier, and that leaves them much more vulnerable than at the moment.

Of course, if your real complaint is that you can't use self-signed certificates to get secure trustable SSL for free, then you're really just a grasping cheap-ass skinflint that is part of the problem, not the solution. The only way they can work is if the certs are pre-distributed to the clients (because anyone can issue them, they can be issued by anyone at all saying anything at all, which is precisely the meaning of untrustable). That. Does. Not. Scale. At. All.

Re:It does its job (0)

Anonymous Coward | more than 2 years ago | (#37684606)

Actually, the only way SSL can be salvaged is if generating self-signed certs is as secure as any other method of signing the certificate.

The proposals that have lots of dispersed machines compare their views of a certificate should be work equally well with centrally signed certs and self-signed. In fact, I haven't heard of any proposal that really fixes the problem without getting rid of the necessity of centralized trust.

It is this centralized trust model that is broken and since current implementations of SSL in browsers use this model, these implementations of SSL are broken.

Re:It does its job (1)

starfishsystems (834319) | more than 2 years ago | (#37686114)

No, SSL is not broken.

First, to address your premise, we are in no position to criticize any protocol merely because some particular implementation of it has been installed with a predefined set of root certs that you don't like. Second, to address your conclusion, it does not logically follow from the premise. QED.

That's not to say that there can be no possible flaws in SSL, though this is a point that you don't address. Both design and implementation vulnerabilities have indeed been identified in SSL, and they have all been successfully fixed. In other words, none have proven so fundamental that SSL can't possibly be fixed, which is what it means to declare that SSL is broken. You can, for example - at the risk of overstating your case - say that SSL 2.0 is broken, but that's no big surprise to anyone. Even so, it would be more accurate to say that it's deprecated.

Browsers have supported SSL 3.0 for years. If you have an application that today relies on behavior specific to SSL 2.0 then it would be correct to say that your application is broken.

I'm happy that we were able to clear up these misunderstandings so easily.

Re:It does its job (1)

Lennie (16154) | more than 2 years ago | (#37688290)

So tell me how does am access provider get a cert signed for a site/domain they don't host.

Isn't the exploit for an old version of TLS? (1)

msobkow (48369) | more than 2 years ago | (#37682742)

Are there no upgrades to TLS 1.0 available? I thought the issue was browsers and websites that hadn't upgraded.

Re:Isn't the exploit for an old version of TLS? (2)

magamiako1 (1026318) | more than 2 years ago | (#37682800)

In Windows land:

IIS 7.5 (2008R2) and at least Windows 7 are required to support TLS 1.1 and 1.2.

In Linux Land:

Apache's mod_ssl does not support TLS 1.1 and 1.2, you need to use mod_gnutls, which is not default on many webservers.

Breaking news! (1)

joeflies (529536) | more than 2 years ago | (#37682782)

Patches fix security flaw. News at 11

He's a Middle Easterner. (-1)

Anonymous Coward | more than 2 years ago | (#37682824)

I don't trust him, and neither should you.

Re:He's a Middle Easterner. (0)

Anonymous Coward | more than 2 years ago | (#37690082)

I don't trust him, and neither should you.

Of course you should. He got a certificate from DigiNotar...

tl;dr: new trust model rumor (2)

colfer (619105) | more than 2 years ago | (#37682870)

He hears rumors in Calif. of a new trust system to complement PKI. That's all he will say when the interviewer questions him repeatedly about a solution to the problem he goes on at length about: that browsers have PKI roots built in. I agree it's a terrible system, but asking the clueless user to select trusted roots would have its own problems, in, say, Iran. Or more precisely, clueless users in the US make it hard to deploy a system for careful users in Iran. The UI has to be both easy & difficult.

Re:tl;dr: new trust model rumor (0)

Anonymous Coward | more than 2 years ago | (#37685654)

I think he's talking about Convergence, the CA replacement system proposed by Moxie Marlinspike

http://news.softpedia.com/news/Researcher-Proposes-Transparent-Replacement-for-CA-System-217067.shtml

Re:tl;dr: new trust model rumor (1)

pairo (519657) | more than 2 years ago | (#37687366)

How would that help if an attacker can inject/remove data, not only sniff it?

Re:tl;dr: new trust model rumor (1)

dkf (304284) | more than 2 years ago | (#37687814)

I think he's talking about Convergence, the CA replacement system proposed by Moxie Marlinspike

The problem is there has to be some way to take old server certificates out of use and replace them with new ones, and that mechanism has to be doable without any signature by either the old certificate or the old CA. Moreover, you can legitimately have multiple certificates for one domain. The upshot of that is that if you pop up a dialog each time you detect such a thing happening, you'll train users to click OK for all security problems, which is an astonishingly bad idea! The advantage of the current system is that it has very few false alarms so users take seriously the problems that are detected.

The real problem is that browser makers have been falling down on their part of the job. It's important that they only include the master certificates of CAs that are genuinely trustworthy. Genuinely trustworthy CAs don't screw the trust system around (though they might charge more than you'd like; c'est la vie) and they ensure that the subordinate CAs that they admit are also trustworthy.

With all these different browser versions... (3, Interesting)

Synerg1y (2169962) | more than 2 years ago | (#37682892)

Why do none support TLS 1.1, firefox is releasing new versions of its browser on an insane schedule, IE is on version 9, chrome is moving along, yet no tls 1.1? Is there something I'm missing here?

Of all the useless features they've implemented in the past year, why not secure the browser? I remember when firefox was proud of it's security.

Then again good luck replacing ssl, what are viable alternatives? Pointless discussion if there aren't any...

Also read carefully about BEAST, it's not a remote exploit, so you can't just click and choose the stream you want to sniff, it's a ways more complicated and requires a high level of trust on the compromised machine.

Re:With all these different browser versions... (2)

AK Marc (707885) | more than 2 years ago | (#37683040)

I checked the Opera I'm using and it allows me to use TLS 1, TLS 1.1, and TLS 1.2, and I can even disable the older ones to make sure I didn't auto-failback to an insecure TLS. Just because Firefox/IE doesn't do it doesn't mean it's not already out there in a free browser.

Then the other browsers need to update (1)

msobkow (48369) | more than 2 years ago | (#37686654)

The argument that most websites haven't been upgraded is insane. The website admins won't upgrade their servers until the browser community can support it.

If Opera is already doing it, they've shown it can be done. Failure to do the same with Firefox, Chrome, et. al. is a sign of either laziness, incompetence, or extremely bad planning.

Stop farting around with 3D support and take care of the security fundamentals first!

Re:With all these different browser versions... (0)

Anonymous Coward | more than 2 years ago | (#37683562)

Firefox discussion thread on TLS issue. [mozillazine.org] The primary counter point seems to be that it largely doesn't matter at this point in time as few servers are currently supporting TLS 1.1 and 1.2. Until such time servers are configured to sanely provide modern TLS support, client support doesn't matter. Furthermore, as is pointed out in the thread, the exploit of TLS 1.0 requires a fairly sophisticated attack (MTM + code injection).

Basically, stories like these are needed to get lazy server admins off their butt. It appears all of the browsers either support current TLS implementations or are actively working toward TLS 1.1 and/or 1.2 support; but few if no one has TLS 1.2 enabled by default. So if you run a server, make sure it supports TLS 1.2 else its you're the weakest link.

Re:With all these different browser versions... (2)

DrXym (126579) | more than 2 years ago | (#37683712)

It's a chicken and egg issue and one that browsers need to force. If the major browser vendors were to multilaterally declare that sites had a 18 month period of grace to support TLS 1.1 / 1.2 after which SSL 3.0 and TLS 1.0 would default to off, then you can sure as hell bet things would start kicking up a gear. Meanwhile browser vendors need to actually implement TLS 1.1 and 1.2 so they can give sites something to test against.

Re:With all these different browser versions... (0)

Anonymous Coward | more than 2 years ago | (#37684014)

You entirely missed the point. The most popular browser already supports TLS 1.0, 1.1, and 1.2. Opera also supports these options. The problem is, even though a sizable chunk supports it, lazy server admins will not enable TLS 1.2 support even though support is available; both client and server. First and foremost, server admins/distributions needs to get off their lazy asses. Clients are not in a hurry because it fixes nothing; as is validated by reality. Server admins are not in a hurry because they are lazy and it WOULD/WILL fix/address known exploits for a sizable chunk of the Internet which in turn will spur rapid client adoption.

This absolutely is not a chicken an egg situation, contrary to foolish contrary statements, specifically because client support already exists. Once IE and Opera offered support (that's what 42+% of the market), it entirely became a lazy admin problem. The fact FF doesn't yet support it is embarrassing but at least they can easily justify such a position on the basis that administrators are absolutely NOT doing their job. Blaming client adoption for lacking server support is illogical and refuted by all known evidence at hand, to say the least. To claim servers should ignore security for 42+% of their clients is insulting and rediculas. Sorry, but lazy admins, get off your asses and do your job.

To claim there needs to be 100% client adoption prior to lazy admins getting off their asses, is illogical, silly, and contrary to their job and users of their services (clients). No ifs, ands, or buts, this absolutely is not a chicken and egg problem; rather, its a lazy admin problem.

Re:With all these different browser versions... (1)

Synerg1y (2169962) | more than 2 years ago | (#37684636)

As did you, what major browsers?

Look here

http://en.wikipedia.org/wiki/Opera_(web_browser)#Market_adoption [wikipedia.org]

You calling opera a major browser and piggy backing off (#37683562) in regards to servers?

IE, Firefox, nor Chrome don't support it as stated above, a 10 second google search would yield something like...

http://www.google.com/support/forum/p/Chrome/thread?tid=0539619c98f85cbb&hl=en [google.com]

It's always worked like... browser implements new feature, web devs and admins follow, if you ask me to to turn on features on a server that aren't in use by anybody... I'd make sure you didn't have a job in my department the next day.

Do not track is a shining example of this concept, shame the implementation is half assed, but it does require web admins to do a little more than change some server settings to implement.

TLS 1.2 would experience the same implementation for a while, so a hard cut over would be nice, but who cares about security when there's money at stake by turning of tls 1.0 and losing revenue from customers who can't hit your site.

It's A LOT more complicated to implement shit in the real world than in your university dmzed lab.

Re:With all these different browser versions... (1)

DrXym (126579) | more than 2 years ago | (#37684884)

Server admins sure as hell will implement a later TLS if suddenly they're inundated with users complaining that various browsers refuse to connect to the site. The smart admins won't be caught out like that. The lazier ones will have to advise users to reenable TLS/SSL temporarily while they get off their asses and fix the thing they had ample warning was about to happen. That's why it needs to be broadcast loud and clear.

As for which browsers implement what, the point is if all browser vendors act in a coordinated fashion on security issues, they'll shape web security a lot faster than acting independently, implementing a patchwork of protocols, and wondering why sites stick with the lowest common denominator.

Re:With all these different browser versions... (1)

Synerg1y (2169962) | more than 2 years ago | (#37685036)

No transition has ever worked that way...

Downtime is not acceptable worldwide rofl.

Browsers would allow tls 1, 1.1, and 1.2 and then figure out what's supported or not by the server. Admins would recognize the hard lined benefits of 1.2 over 1.0 especially in shops that care about their security and set their servers to 1.2 only. In a few years, more and more people would adapt 1.2 until 1.0 can finally be phased out with a broadcast like message that you are implying.

Let me be clear though, unless there is a compelling reason for a hard cut over, it should never happen, nobody deserves to have their site knocked out of the loop because their web admin sucks or they haven't been paying attention (ex. incorrect DNS contact info). Cut overs occur with 99% planning and 1% doing, and downtime is factored out whenever possible, such as here lol.

Re:With all these different browser versions... (1)

DrXym (126579) | more than 2 years ago | (#37687866)

As I said, give them a large notice period and a schedule and then disable the old protocols by default in browsers. Users can still enable the old protocols but suddenly browsers become secure by default. It wouldn't stop sites downgrading to older protocols for older browsers but it would hugely diminish the attack surface and vulnerability going forward.

And yes it can work assuming the major browser companies were united behind a single plan. Sites would have to change and the large majority would change. And those that didn't... well tough good luck handling the support calls.

Security transitions happen all the time, e.g. Sky TV sends out new decoder cards every few years, provides an overlap period to cover the changeover and then kills the old cards. Browsers have got to start coordinating some security changes too.

Re:With all these different browser versions... (1)

Synerg1y (2169962) | more than 2 years ago | (#37690590)

Really?

I'd just tell my users not to upgrade and block the update via the ASA till I got off my ass, you realize I actually do this shit professionally don't you and it just doesn't work your way, never did, never will?

Never heard of sky TV, not a comparable scope though, tiny company vs the planet earth? Keep dreaming.

Re:With all these different browser versions... (0)

Anonymous Coward | more than 2 years ago | (#37685148)

Why do none support TLS 1.1, firefox is releasing new versions of its browser on an insane schedule, IE is on version 9, chrome is moving along, yet no tls 1.1? Is there something I'm missing here?

Of all the useless features they've implemented in the past year, why not secure the browser? I remember when firefox was proud of it's security.

Firefox may have a wide developer base, but NSS (Netscape Security Services), the cryptographic library that Firefox uses, does not. It was maintained mostly by developers from Red Hat and Sun Microsystems. In the last 5 years, many of those developers have moved on to other jobs / companies and maintain NSS in their spare time.

Pledging for automatic updates? (2)

praseodym (813457) | more than 2 years ago | (#37682938)

The guy is pledging for automatic updates:

We have to build a mechanism to automatically update things. We did not do that. The right way to design, if we were to update things an updating protocol that automatically updates itself so when the next version comes up it knows where to find the next version rather than having to wait for a Windows update or whatever.

Actually, newer windows versions (Vista and later) use Microsoft's online Certificate Trusts Lists which allows exactly this. Microsoft revoked the DigiNotar certificate without issuing a real Windows update:

On August 29, 2011, Microsoft removed the trust from one DigiNotar root certificate by updating the Microsoft CTL. Why is Microsoft releasing an update? Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 use the Microsoft Certificate Trust List to validate the trust of a certification authority. Windows XP and Windows Server 2003 do not use the Microsoft Certificate Trust List to validate the trust of a certification authority. As a result, an update is needed for all editions of Windows XP and Windows Server 2003 to protect customers.

(http://technet.microsoft.com/en-us/security/advisory/2607712)

Re:Pledging for automatic updates? (1)

Taty'sEyes (2373326) | more than 2 years ago | (#37683278)

WOW! What else can this amazing operating system do? Who makes this? Micro What?

Re:Pledging for automatic updates? (1)

Beeftopia (1846720) | more than 2 years ago | (#37683450)

Actually, newer windows versions (Vista and later) use Microsoft's online Certificate Trusts Lists which allows exactly this. Microsoft revoked the DigiNotar certificate without issuing a real Windows update:

Single point of failure.

Re:Pledging for automatic updates? (1)

Anonymous Coward | more than 2 years ago | (#37684582)

Actually, newer windows versions (Vista and later) use Microsoft's online Certificate Trusts Lists which allows exactly this

No it doesn't. What Microsoft does is disable certficates.

Taher Elgamal is talking about automatically patching/updateing the SSL protocol itself, not just some certificate disabling. Nice idea, but noway that is going to happen in any serious environment. Just like with any other update, anyone taking his systems seriously will want to test this before deploying. Especially because this is about a communication protocol. Just imagine your VPN tunnels failing because the product on one end of the tunnel was "updated"causing an incompatibility with another product on the other end of the tunnel.

mod dowN (-1)

Anonymous Coward | more than 2 years ago | (#37683008)

Departures of Tangle of fatal reasons why anyone FrreBSD showed of playing your [gay-sex-aacess.com]? OS don't fear the

The solution is to throw out CAs (1)

spottedkangaroo (451692) | more than 2 years ago | (#37683248)

I used to be in favor of patching things with DNSSEC, until I thought about it. I didn't really think about it until I saw moxie's blackhat talk. I happened to see it live, but not at blackhat. It's great. I think it's also a bulletproof argument against the CAs and DNSSEC. The protocol itself can be fixed (the security attack), but the current CA system pretty much can't be in a way that would satisfy me after seeing the talk.

http://www.youtube.com/watch?v=Z7Wl2FW2TcA [youtube.com]

http://convergence.io/ [convergence.io] (this is only a prototype, it could be rolled into openssl or whatever, with caveats, some day)

Re:The solution is to throw out CAs (0)

Anonymous Coward | more than 2 years ago | (#37684612)

Hooray, you managed to kill the youtube link. Grats.

Re:The solution is to throw out CAs (1)

Lennie (16154) | more than 2 years ago | (#37688326)

While I really like the concept, I'm not sure how well this will work in practise scale.

The thing I like least about it is that it caches known certs for as long as the cert is valid.

How do people revoke certs of compromised keys in that model ?

Re:The solution is to throw out CAs (1)

spottedkangaroo (451692) | more than 2 years ago | (#37689894)

There are problems with this approach, but they're no worse than the CA-SSL model. In fact, they're quite a bit more survivable. And anyway, the idea is young. It will get better.

Regarding revocations. Do you really (honestly) subscribe to any revocation lists now? I've done this in the past, but I haven't done it for years and I care about this topic very much. The problem is the same with CA-SSL vs Convergence-SSL only with convergence you can sometimes detect the problem and with CA-SSL, you'll almost never spot it. Really, if someone gets a fake cert from a CA, there's nothing you can do to detect it under CA-SSL. If they steal a cert from your favorite website, and the owners happen to notice, they'll make a new cert, issue a revocation that *NOBODY* checks and then there you go, you won't notice. Convergence will ask the notaries about it when it doesn't match the cache.

In the rather extreme case where all your connections are owned byThe Man, they happen to have a fake cert (stolen or legit, like from DHS), and they happen to know you have it in your cache (for the stolen case); then the two approaches come out sorta the same: there's really no way for you to detect it.

But I think in most situations convergence will do a better job. Firstly, the man won't know what notories you're using (well, today there's only two that I know of) and second, they won't know what you have cached. If we moved to DNSSEC, The Man only needs to provide for you some fake dns responses, signed completely legitimately by '.', .org. or whomever they've (theoretically) strong armed into cooperating.

Re:The solution is to throw out CAs (1)

Lennie (16154) | more than 2 years ago | (#37692084)

No revocation lists are usually huge, like 200MB+ so pretty much useless.

But you don't need a revocation list to revoke a certificate in any moden browser. It usually supports OCSP.

I believe browsers don't cache OCSP-responses longer than the browsing session (for as long as the browser is open) ?

So if you enable "When an OCSP server connection fails, treat the connection as invalid" you will be 'safe'.

Next time you start the browser OCSP is checked, thus if the certificate is revoked you would get a proper error.

I would have liked it more if the notaries are checked more often, instead of just ones per certificate (thus: ones and never again) as it is now.

Which obviously might be a scalability problem.

Re:The solution is to throw out CAs (1)

spottedkangaroo (451692) | more than 2 years ago | (#37696312)

You're probably right. I have no idea how OSCP actually works, just nebulous ideas about how it probably functions. I don't think it changes much with respect to my (er, moxie's) arguments though. Who really has this turned on anyway? How does it solve the trust problems inherent with the CA-SSL model?

Local caching is a personal decision and it's a setting even in the prototype. You can choose to cache, or not. You can choose your notaries, or use the defaults. You can also choose between simple majority and any member failure and some other things. The entire point is that the trust is in YOUR hands, not in some organization you've never heard of, or heard of but don't wish to 100% trust, forever (eg verisign, dhs, comodo).

Re:The solution is to throw out CAs (1)

Lennie (16154) | more than 2 years ago | (#37699368)

Forgot about that, you can turn off the cache. I don't currently use it, I was actually looking at the source on github. :-)

Anyway, I keep wondering how it will scale in general, like how would the general public who knows nothing about these settings and how it works or how to use it.

For example let's say you have many, many people using the same notary as a default in the browser, you could never ever turn it off.

Re:The solution is to throw out CAs (1)

Lennie (16154) | more than 2 years ago | (#37699396)

Something else I'm thinking.

If this gets introduced to the general public.

The first thing that will happen immediately is that when you install your new Windows Anti-Virus software the vendor will implement their own and just add their notary to the list.

Let me guess the OEM will add it's own notary as well ?

This all seems like a bad idea.

I don't know, maybe I'm just in a negative mood :-)

Re:The solution is to throw out CAs (1)

spottedkangaroo (451692) | more than 2 years ago | (#37699486)

Right now there's only one notary... er, two ... But later, if this catches on at all, there'd be like 30 or a thousand... and your client would probably pick randomly the first time. And if one failed, you'd just skip that one and use another (depending on your settings of course). I can imagine a hundred ways around the scalability problems (in your browser anyway).

Actually, Moxie talks about what happens if some of your notaries are untrusted. Since the FBI or the credit card thief will never know which notaries you're using, even the sinister answers from evil notaries are still helpful -- they won't agree with the good guy notaries, nor even with the other evil notaries.

Re:The solution is to throw out CAs (1)

spottedkangaroo (451692) | more than 2 years ago | (#37699498)

(Didn't really finish my thought: So if the OEM adds its own notary, you don't really lose anything as long as there's a couple others on the list too.)

Impossible to say? (1)

carcomp (1887830) | more than 2 years ago | (#37683306)

Talks Serious Security Turkey... I had to read that four times before it actually made sense. Talks securitious security... turkey security.. Sorry for the randomness, but I wouldn't have even clicked this article had it not been for the title being so weird.

Re:Impossible to say? (0)

Anonymous Coward | more than 2 years ago | (#37683596)

Just "Talks Turkey" would have been enough. That tells us it is "serious" and by the context we know it is about "security."

I don't really understand the point of using the idiom at all if you're just going to repeat everything and mangle the idiom while doing it.

Re:Impossible to say? (1)

Thud457 (234763) | more than 2 years ago | (#37684336)

I'm sorry, like all users, all I heard was:

Father of gobble Talks Serious gobble gobble
Posted by Unknown Lamer on Tuesday October 11, @03:27PM
from the trust-me-i-invented-a- gobble - gobble dept.

coondoggie writes:

with an excerpt from a gobble World article:

" gobble / gobble , the gobble that protects gobble of e- gobble , has taken a beating lately, with news items ranging from the gobble of gobble gobble s to the discovery of an gobble that beats the gobble itself. But despite the gobble ... and the failures of gobble gobble such as Gobble and Gobble that are supposed to gobble users, the gobble has a lot of life left in it if properly gobble ed as it becomes gobble , says Gobble Gobble , gobble of gobble and one of the creators of gobble .

Re:Impossible to say? (0)

Anonymous Coward | more than 2 years ago | (#37688798)

I tried picturing a 'security turkey' and it somehow came out as bondage in my head... the hell is wrong with me?

and the captcha of 'redneck' somehow seems fitting.

Security Turkey? (1)

The Grim Reefer2 (1195989) | more than 2 years ago | (#37683538)

Wasn't Canadian Thanksgiving yesterday?

Re:Security Turkey? (0)

Anonymous Coward | more than 2 years ago | (#37683804)

Well yes, but there's still quite a bit of turkey left over.

And people typically secure their turkey before Thanksgiving, but give it little thought after. It's nice that this guy cares about turkey security, in all it's forms.

BEAST, TLS 1.0 v. 1.1, CA model, security upgrades (1)

Onymous Coward (97719) | more than 2 years ago | (#37685034)

Summarizing...

BEAST, TLS 1.0 v. 1.1
The BEAST attack is somewhat a concern for TLS 1.0, just how practical the attack is has yet to be seen. Requires malware on your the system, so he says, which means you've already lost the game. Moving to TLS 1.1 would protect against BEAST, but is problematic because of lack of support.

CA System, upgrades

Is there a better way than certificate authorities?

The fact that browsers were designed with built-in root keys is unfortunate. That is the wrong thing, but it's very difficult to change that. We should have separated who is trusted from the vendor. If we cannot separate the root of trust from the vendor then the best we can do is build a side reputation system that everybody consults.

Dreaming Up Alternatives
He posits a system with some "trust agility" (as Marlinspike calls it), wherein CAs have reputations and can be updated, rather than are baked into the browser.

And the root of the trust should be the Internet with its built-in reputation ecosystem. All the CAs will have reputations built in because that's how the Internet runs, and then you have a better trust model that way.

Exact model for how and from whom we source reputation ratings not explained: "And I'm not saying I know how to implement this, but it's a better model. ... It will just be done in the ecosystem."

Then the interview at first seems to veer back to the protocol implementation. He talks about updating the protocol's software automatically, I assume like Firefox or its plugins, or Windows Update. But I think he's seeing the CA authorizations and protocol implementation as a unit, so they both get updated.

Sound like he's leaving the decision on the roots still with your software provider. I think it should be more "agile" than that, more individually-configurable if so desired.

Existing Alternatives
The Perspectives/Convergence model has us looking at what others, from a variety of network locations, see as the certificate for the site we're visiting. (And maybe also how long those other locations have been seeing what they see. (Perspectives does this.)) This is a very basic "reputation score"; notaries just tell us their perspective, which we then analyze to determine whether we think the cert we see is good.

Hybridizing
How we choose notaries is a concern. I envision sysadmins sharing notary installations between themselves, but what happens for nontechnical people? It may make sense to have third parties rating notaries, and providing "subscriptions" to their ratings. So you could subscribe to the "EasyList Trustable Notaries" or the "EFF Notaries" lists. As notaries come and go, or as notaries prove themselves untrustworthy, these organizations would update their lists and your subscription would automatically update the notaries your browser uses.

Alternatively, have the list be not of notaries, but CAs themselves. It could replace your browser's baked-in CA list. This, however, doesn't allow people to use self-signed certs, it still rests on the precarious infrastructure of race-to-the-bottom CAs, and it doesn't solve the problem of how a quarter of the SSL web becomes untrustable as soon as Verisign fucks up. This is why I prefer the notary route.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>