×

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!

SSL Still Mostly Misunderstood, Even By the Pros

timothy posted more than 4 years ago | from the duh-it's-encrypted dept.

Security 292

An anonymous reader writes "People still don't understand SSL. This isn't much of a surprise... no one expects that grandma and grandpa know what SSL is and what it does. What is surprising and downright scary is that most IT professionals don't understand SSL, and many consider it to be the be-all, end-all of security in their organization. With all the tools out there to manipulate SSL connections, and the browser vendors unable to settle on a single method of showing if a site is secured by SSL or not, is it any wonder that no one gets it?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

292 comments

I'm a Pro (1, Funny)

Anonymous Coward | more than 4 years ago | (#29717297)

What is SSL anyway?

As usual, no one wants to be the leader. (5, Interesting)

Futurepower(R) (558542) | more than 4 years ago | (#29717499)

This article would be funny if it weren't so sad. What's the reason computer professionals don't understand SSL? Bad documentation. And neither the Slashdot summary or the article to which Slashdot links is willing to link to documentation.

The Wikipedia explanation of SSL [wikipedia.org] helps. This explanation [ssl.com] helps, also.

The Do It Yourself SSL Guide [webopedia.com] is useful.

Re:As usual, no one wants to be the leader. (2, Insightful)

upuv (1201447) | more than 4 years ago | (#29718061)

I blame JAVA.

Java dev to any other IT dude: "I don't need to know about that the jvm abstracts that away for me. So buzz off and let me do real IT work. "

Just kidding :) Well actually I'm not. In general Java devs know ZIP about anything out side of a JAR file.

Re:As usual, no one wants to be the leader. (3, Informative)

Chrisq (894406) | more than 4 years ago | (#29718477)

In general Java devs know ZIP about anything out side of a JAR file.

They may not even know that JAR files are ZIP format.

Moderators, are you all friggin' retards? (4, Insightful)

Eggplant62 (120514) | more than 4 years ago | (#29717299)

Who proofreads these article submissions, anyway? Does anyone?

Re:Moderators, are you all friggin' retards? (1)

Beyond_GoodandEvil (769135) | more than 4 years ago | (#29717313)

Who proofreads these article submissions, anyway? Does anyone?
Used to be able to tag a story with typo to let the editors know what's going on. Glad to see I'm not the only one jarred by the second their in the summary.

Re:Moderators, are you all friggin' retards? (0)

Anonymous Coward | more than 4 years ago | (#29717341)

Used to be able to tag a story with typo to let the editors know what's going on.

Right...no typo tag allowed ?!? Does that mean tagging was trolled to death?

Re:Moderators, are you all friggin' retards? (5, Funny)

Stachybotris (936861) | more than 4 years ago | (#29717349)

no one expects that grandma and grandpa know how to what SSL is and what it does.

I just consider this sort of typo a cheap and lazy form of story encryption...

Re:Moderators, are you all friggin' retards? (0, Troll)

L4t3r4lu5 (1216702) | more than 4 years ago | (#29717459)

Xvaq bs yvxr hfvat n ebgngvbany plcure

Re:Moderators, are you all friggin' retards? (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29718019)

Ebgngvbany plcuref ner njrfbzr

Re:Moderators, are you all friggin' retards? (1, Funny)

Anonymous Coward | more than 4 years ago | (#29717679)

Hey! I *do* know how to what.

It is what to how which is somehow not what you will.

xtracto

Re:Moderators, are you all friggin' retards? (5, Funny)

rockbottoms (1393173) | more than 4 years ago | (#29717933)

I just consider this sort of typo a cheap and lazy form of story encryption...

I just except the typos for what they are

Re:Moderators, are you all friggin' retards? (1)

G'grandpa (1654849) | more than 4 years ago | (#29717621)

Who proofreads these article submissions, anyway? Does anyone?

Any high school graduates out [their, they're, there]?
"...all the tools out their to manipulate..."
Perhaps the moderators let this pass on purpose to emphasize the educational failings in our English speaking (sic) cultures.

- English speaking Grandpa (actually a Great Grand Father)

Re:Moderators, are you all friggin' retards? (0)

Anonymous Coward | more than 4 years ago | (#29718277)

Replace all occurrences of "SSL" with "English" in the article. Then it makes sense.

Example: "People still don't understand English. This isn't much of a surprise..."

You're doing it wrong (4, Informative)

QuantumG (50515) | more than 4 years ago | (#29717309)

If you want to write a pretentious article about how people don't understand security of the interwebs, at least get the name right [wikipedia.org]. That's right, SSL hasn't been considered "secure" for at least a decade.

Re:You're doing it wrong (3, Insightful)

frozentier (1542099) | more than 4 years ago | (#29717335)

If you want to write a pretentious article, AT LEAST use correct spelling and grammar if nothing else.

Re:You're doing it wrong (5, Insightful)

Anonymous Coward | more than 4 years ago | (#29717369)

The article isn't even just pretentious, it's just pointless fluff. The entire thing could have been summarized as "many customers ignore security warnings in browsers and many web developers deploy SSL/TSL in vaguely unacceptable ways which we won't even begin to explain here".

Really, that article couldn't have been more pointless. WHAT are people doing that they shouldn't be? WHAT are people expecting SSL to do that it doesn't? If you're going to write an article about people's misconceptions of a technology, you could at least spend a single sentence explaining what some of those misconceptions are.

Pointless and uninformative article is pointless and uninformative.

Re:You're doing it wrong (1)

Magic5Ball (188725) | more than 4 years ago | (#29718053)

FTFA:

> "Reguly's survey found that while 83 percent of users check they're using an SSL-secured session before entering their credit card information on a Website, only 41 percent do so when typing in their passwords."

> "More than half of the respondents don't know what Extended Validation SSL (EVSSL) is and how it differs from SSL, while 36 percent say they do. Interestingly, most of them are aware that SSL traffic can be sniffed without their knowledge."

> "Another issue is that users become annoyed and eventually ignore SSL and browser security messages that appear when they hit a site with an invalid certificate, or a browser warns them of a potentially dangerous site, Reguly says. Nearly 50 of the survey's nontechnical respondents just clicked through security warnings without paying attention to them, he says."

Re:You're doing it wrong (2, Insightful)

yuna49 (905461) | more than 4 years ago | (#29718419)

> "Reguly's survey found that while 83 percent of users check they're using an SSL-secured session before entering their credit card information on a Website, only 41 percent do so when typing in their passwords."

I found this one of the silliest parts of the story. First, to what type of sites does that 41% figure apply? Are they the same sites where people are entering credit card information? There are a number of sites where I enter passwords without SSL encryption, this site for one. Those are sites where I don't really care if my password is sniffed or not. Does that place me in the 59% of supposedly inattentive users? For sites where I care about protecting my authentication information like my bank or Amazon, I make sure the password transaction is encrypted.

Next, the article presents a laundry list of apparent security flaws in SSL. How common are these? Do we have demonstrated evidence that they've been used to subvert transactions with well-known sites like major banks and online retailers, or are these just theoretical flaws? Like the article on piracy in today's news, the statistics in this piece seem intended to drive sales of security software and services by fear-mongering.

Finally there's the suggestion that browsers never permit people to accept certificates that have expired or are self-signed. I'm sorry, but that's just not going to fly. I find the current plethora of hoops I have to jump through with Firefox annoying enough. If I want to sign a cert so my employees can read their mail with a web browser, what's wrong with that?

Re:You're doing it wrong (1)

vadim_t (324782) | more than 4 years ago | (#29718491)

Finally there's the suggestion that browsers never permit people to accept certificates that have expired or are self-signed. I'm sorry, but that's just not going to fly. I find the current plethora of hoops I have to jump through with Firefox annoying enough. If I want to sign a cert so my employees can read their mail with a web browser, what's wrong with that?

That it's pointless and doesn't work?

If your employees every day click on "Ignore self-signed cert" button, then they'll click on it the time when they connect to some random open access point that's set up to generate self-signed certs for any SSL website.

It's worse than no encryption. With no encryption you know there isn't any security. With encryption you think there is, all while your internal company mail is passing through a system intentionally set up to log all traffic for malicious purposes.

You can fix it easily though. All you need is to setup your own CA. Use something like tinyca. Generate a CA cert, make certs for your employees, sign then with the CA, then get them to import the CA certs into their browsers. Then any further certs you sign with that CA will be automatically trusted. Every browser will stop complaining if you give it your CA cert.

Re:You're doing it wrong (5, Informative)

something_wicked_thi (918168) | more than 4 years ago | (#29717387)

If you want to write a pretentious response to a pretentious article, try reading the source you're linking to. SSL v2 hasn't been secure for a while, but SSL v3 is fine.

Re:You're doing it wrong (5, Insightful)

Antique Geekmeister (740220) | more than 4 years ago | (#29717651)

No, I'm afraid it's not. It's still vulnerable to "Do you accept this made-up key" attacks where people have become far too accustomed to accepting unsigned keys, and to the purchase of centrally signed keys. Because the key signatures belong to a central signing authorities that rely on valid credit cards, not personal authentication, there is still only a pretense at genuine security.

There have been other tools proposed to address these issues, such as the PGP web-of-trust, and the Palladium project's hardware encryption, but they've broken down in practice on the problem of US encryption export regulations, poor closed source implementation that turns out to be easily virtualized, and many essentially social rather than technological issues. Even SSL was handicapped for years by the USA's insane 80-bit limit for SSL in exported software.

Re:You're doing it wrong (3, Informative)

muckracer (1204794) | more than 4 years ago | (#29717805)

> Even SSL was handicapped for years by the USA's insane 80-bit limit for SSL
> in exported software.

It was 40-bits. Agree with your point...just sayin'.

Re:You're doing it wrong (4, Insightful)

rgviza (1303161) | more than 4 years ago | (#29718051)

>No, I'm afraid it's not. It's still vulnerable to "Do you accept this made-up key" attacks where people have become far too accustomed to accepting unsigned keys, and to the purchase of centrally signed keys

Um, that's a social engineering attack, not a fault of the protocol itself. The protocol is secure, users aren't. To be fair, the browser manufacturers could do a better job of writing the warnings so that anyone could understand them. Again, this is not a fault of the protocol, rather how people use it.

And adding a layer of PGP to it, would have the _exact_ same issue. Instead of "Do you accept this SSL key" It would be "Do you accept this PGP key". In addition, adding PGP would introduce a whole new slew of security bugs related to added complexity of PGP support in browsers, along with all the bugs guaranteed to be introduced with the additional new code.

No thanks =D.

Re:You're doing it wrong (1, Informative)

Anonymous Coward | more than 4 years ago | (#29717411)

Whatever, everyone uses TLS and SSL interchangeably because they are for all intents and purposes the same. SSLv3 is secure but you do have the possibility of man-in-the-middle attacks. That is true of all public key based systems though (including SSH, etc).

Re:You're doing it wrong (1)

andymadigan (792996) | more than 4 years ago | (#29717653)

That's what certificate signing is supposed to protect against. Of course, if you have $100 million lying around or you're the government, you can probably get certificates signed for domains you don't own, and they'll look real. That's why we need a public database of certificates that browsers check against, rather than signing certs.

Re:You're doing it wrong (2, Insightful)

Magic5Ball (188725) | more than 4 years ago | (#29718137)

I think the idea of a public revocation database has merit. How would I make sure that my connection to the database has not been tainted? How could this database as a business entity be designed in a way that's less vulnerable to social engineering attacks than the current system?

You didn't get it right either... try "HTTPS" (4, Informative)

WD (96061) | more than 4 years ago | (#29717435)

The correct term is "HTTPS". HTTPS, which can use various versions of SSL or TLS, is still mostly understood. Even by the pros.

Re:You didn't get it right either... try "HTTPS" (0)

Anonymous Coward | more than 4 years ago | (#29717705)

That's like saying the correct term is "car" when you're talking about a wheel.

You actually mean "Public Key Cryptography" and how to apply it.

Re:You didn't get it right either... try "HTTPS" (0)

Anonymous Coward | more than 4 years ago | (#29717995)

That's like saying the correct term is "wheel" when you're talking about a cylinder.

You actually mean "Math" and how to apply it.

Re:You didn't get it right either... try "HTTPS" (0)

Anonymous Coward | more than 4 years ago | (#29717941)

I fall in the line of not having a clue what TLS is, or what it means.

Although i rarely wander out of the same usual sites these days.
I blindingly trust the usual huge sites (google, paypal, etc), but anything small and I'm like "oh hell no, let's just find out some stuff about you, you just gained a stalker!"

TLS vs SSL (1)

Frankie70 (803801) | more than 4 years ago | (#29718151)

TLS 1.0 is based on SSL v3. TLS 1.0 is also called SSL 3.1 sometimes.
There isn't really a huge difference between TLS & SSL 3.0.

I liked netscape's method (1, Informative)

Anonymous Coward | more than 4 years ago | (#29717315)

"browser vendors unable to settle on a single method of showing if a site is secured by SSL or not"

They put a thin but obvious blue border around the entire browsing window. Why does Firefox not let you select among a few different methods? I know not.

Re:I liked netscape's method (0)

Anonymous Coward | more than 4 years ago | (#29717675)

Why does Firefox not let you select among a few different methods? I know not.

THIS CONNECTION IS UNTRUSTED

You have asked Firefox to connect securely to this website, but since whoever signed their certificate hasn't paid us thousands of dollars to treat their certificates as 'safe', we can't confirm that your connection is secure. So even if it your blog's admin panel and you use a self-signed certificate, you have to jump through hoops to continue. All in the interest of protecting stupid people and making Verisign boatloads of easy money.

[Get me out of here!]

[I understand the risks and want to have to click another 10 times to view the website]

Re:I liked netscape's method (1)

EXrider (756168) | more than 4 years ago | (#29718169)

Yeah, we'll we'd all like to see Verisign and the like not charge a fucking arm and a leg for a cert used to secure a webmail server, a mythweb server, etc.

I use StartSSL [startssl.com], they're a pretty decent provider of free class 1 certs, and their root certs are already in every major browser except IE, and they provide a nice lil' page that you can link to, to install the root certs into IE (after clicking through like 8 IE warning dialogs, no joke). They also use RSA for the signing algorithm, not that MD5 crap [slashdot.org]. You can also add their root certs to the domain certificate policy in Active Directory to get the root certs automatically distributed to all the IE users in your domain.

SSL is dead for 10 years (2, Insightful)

Anonymous Coward | more than 4 years ago | (#29717345)

SSL is no more for 10 years.

You have to copy TLS 1000 times on the blackboard :
http://en.wikipedia.org/wiki/Transport_Layer_Security
http://tools.ietf.org/html/rfc2246

SSL has 7 times as many hits as TLS (4, Funny)

tepples (727027) | more than 4 years ago | (#29717689)

Good luck. Google has 9,610,000 hits for ssl certificate and 1,350,000 hits for tls certificate.

and WHY doesn't Slashdot use HTTPS? (0)

Anonymous Coward | more than 4 years ago | (#29717405)

I want security in my browsing... why doesn't Slashdot offer THEIR content over a secure HTTPS connection? I don't want anyone to know that I read the "idle" section and which posts I read.

Re:and WHY doesn't Slashdot use HTTPS? (1, Informative)

Anonymous Coward | more than 4 years ago | (#29717427)

Performance overhead of encrypted connections, we can't even get UTF8 due to performance concerns, what makes you think we're going to get HTTPS?

Re:and WHY doesn't Slashdot use HTTPS? (5, Informative)

pjt33 (739471) | more than 4 years ago | (#29717469)

How would HTTPS help? You'll still probably do an unencrypted DNS lookup for idle.slashdot.org.

Re:and WHY doesn't Slashdot use HTTPS? (2, Informative)

Anonymous Coward | more than 4 years ago | (#29717533)

Not to mention the fact that the GETs will have to have their endpoint identifiers unencrypted, and so the IP addresses will be available, which means they'll know how MANY requests you've made to /.

Re:and WHY doesn't Slashdot use HTTPS? (0)

Anonymous Coward | more than 4 years ago | (#29717923)

I was trying to be funny. "woosh" would be an appropriate noise to make now.

Re:and WHY doesn't Slashdot use HTTPS? (1)

Just Some Guy (3352) | more than 4 years ago | (#29717847)

why doesn't Slashdot offer THEIR content over a secure HTTPS connection?

Probably because it'd be freakishly expensive to pay for that much computing horsepower for something that just doesn't matter. Don't want people to know you read idle? Then don't read idle from places where you don't want to be monitored. Honestly, it's not like someone's snooping your online banking.

Re:and WHY doesn't Slashdot use HTTPS? (1)

smoker2 (750216) | more than 4 years ago | (#29718005)

Computing horsepower ? It's ok for slashdot to inflict painful javascript and useless CSS on us but if THEY have to implement a fairly light security system it's too much ! fuck off.

Re:and WHY doesn't Slashdot use HTTPS? (1)

Just Some Guy (3352) | more than 4 years ago | (#29718283)

It's ok for slashdot to inflict painful javascript [...] on us but if THEY have to implement a fairly light security system it's too much !

In other news, it's easier to distribute work across a million clients than to build one server to do the same amount of work.

[...] and useless CSS [...]

Oh, you're one of those table-layouters. I apologize for wasting your time with references to modern technology.

Re:and WHY doesn't Slashdot use HTTPS? (1)

muckracer (1204794) | more than 4 years ago | (#29718017)

> it'd be freakishly expensive to pay for that much computing horsepower for
> something that just doesn't matter.

So what about the login/password?

Re:and WHY doesn't Slashdot use HTTPS? (1)

Just Some Guy (3352) | more than 4 years ago | (#29718349)

So what about the login/password?

Now, that's a valid and appropriate use. It doesn't buy you much over digest authentication [wikipedia.org], though, and that's supported by almost everything but IE5.

Re:and WHY doesn't Slashdot use HTTPS? (1)

Nursie (632944) | more than 4 years ago | (#29718159)

Why not do what I do?

SSH tunnel into home, with Firefox pointed at a dynamic port forward to use as a SOCKS server. Then go into about:config and activate the setting for DNS lookups through proxy.

Voila, now all work can see is you transferring encrypted data to and from home. They may think you're into industrial espionage, but they'll never be able to tell you were visiting /.

SSL is trying to do too much. (5, Insightful)

argent (18001) | more than 4 years ago | (#29717423)

Forcing people to implement both privacy and authentication in one package is half the problem with SSL. For most sites, it's more important to know that the site you're visiting is the same site you visited last time, than knowing that foo.example.com has a signed certificate approved by someone you never heard of. If these two functionalities were separated, so the browser just checked that a "non-certified" site's encryption key hadn't changed and let you through without comment if that was the case, then most sites using old or self-signed certificates would just use the encryption layer, and browsers COULD block access to sites with invalid certificates without causing people so much inconvenience they'd want to switch to a different browser that was less picky.

(yes, I know that this would probably be implemented using self-signed certificates, but it could be presented to the user as a "low security" site with an appropriate icon and at most a comment that "you haven't visited XXXX.example.com before, it is a low security site..." the first time you see it)

Re:SSL is trying to do too much. (1)

Lennie (16154) | more than 4 years ago | (#29717485)

The problem with this is, certificates expire.

Re:SSL is trying to do too much. (1)

argent (18001) | more than 4 years ago | (#29718035)

Self-signed certificates can be regenerated automatically, or simply set to have a renewal date after the world ends in 2038.

Re:SSL is trying to do too much. (0)

Anonymous Coward | more than 4 years ago | (#29718331)

So you are saying you shouldn't change the public/private key for for 20 something years? How is that secure?

Re:SSL is trying to do too much. (5, Insightful)

Drencrom (689725) | more than 4 years ago | (#29717517)

Totally agree with this. If I dont want to spend money paying a certification authority I should be able to encrypt anyway without the browser warning the user in big red letters that I am a pirate. Firefox warnings are geting worse in each version and, for the user perspective, it seems that encrypting with a non official certificate is much worse than not encrypting at all. By the way I use cacert [cacert.org] to generate my certificates; it should be inlcuded in the default Firefox certification authorities list. I suspect there is money involved in getting into that list though.

Bug 215243 (5, Informative)

tepples (727027) | more than 4 years ago | (#29717747)

By the way I use cacert to generate my certificates; it should be inlcuded in the default Firefox certification authorities list. I suspect there is money involved in getting into that list though.

CAcert failed a DRC audit. Bug 215243 comment 158 [mozilla.org] has the details.

Re:SSL is trying to do too much. (1)

itsdapead (734413) | more than 4 years ago | (#29717823)

Totally agree with this. If I dont want to spend money paying a certification authority I should be able to encrypt anyway without the browser warning the user in big red letters that I am a pirate.

Except, if you don't verify the identity of the recipient, encrypting data is as much use as putting a steel door on a tent. Maybe that's why encryption and authentication are joined at the hip?

The behaviour of Firefox is absolutely correct: it strongly discourages people who don't know any better from connecting to unverified sites, but does not prevent it.

If you want to run an encrypted site without shelling out for a certificate, then fine - but its up to you to reassure visitors that you're not evil.

The real problems are that (a) its such a hassle to drill down to the name of the certificate holder and (b) when you do find it its usually something like "No Obvious Connection to the Website Corp. (Holdings) PLC". (the extended ID in Firefox helps, where its used).

Re:SSL is trying to do too much. (1)

argent (18001) | more than 4 years ago | (#29718113)

If you want to run an encrypted site without shelling out for a certificate, then fine - but its up to you to reassure visitors that you're not evil.

There's nothing stopping an evil company from getting a certificate. Consider Microsoft as an example. Or Verisign. Or Aristotle.

What you mean to say is "it's up to you to convince your visitors that you're who you say you are".

If all I'm saying is "I'm a video game web forum" then my visitors don't need anything more than "I'm using the same self-signed certificate I used the last time".

Re:SSL is trying to do too much. (1)

dkf (304284) | more than 4 years ago | (#29718231)

If all I'm saying is "I'm a video game web forum" then my visitors don't need anything more than "I'm using the same self-signed certificate I used the last time".

Frankly, a video game web forum doesn't need encryption except for the matter of identifying users, and something like OpenID could be used for that.

Re:SSL is trying to do too much. (1)

vadim_t (324782) | more than 4 years ago | (#29718389)

Any company can get a cert.

What's important is that they're not supposed to be able to get one for a domain not of their own. So for instance, a Microsoft employee can't get a cert for paypal.com then sit somewhere between your network and the internet and perform a man in the middle attack.

Re:SSL is trying to do too much. (1)

Hatta (162192) | more than 4 years ago | (#29718279)

What use is encryption if you can't guarantee that there's not a man in the middle? This is why self-signed certs are a bad idea. That is, unless you want your users calling you up to manually verify your key.

Re:SSL is trying to do too much. (1, Flamebait)

ObsessiveMathsFreak (773371) | more than 4 years ago | (#29718455)

Firefox warnings are geting worse in each version and, for the user perspective, it seems that encrypting with a non official certificate is much worse than not encrypting at all. .... I suspect there is money involved in getting into that list though.

The only sane reason I can come up with for the continuing insanity of the Firefox self signed cert warnings is direct kickbacks to the Mozilla foundation from Verisign and the like. I have little doubt that at the very least, "consultation" with Verisign and the like lead to that ridiculous yellow policeman and his preference for plaintext or paid certificates.

Self signed certs serve a purpose. They offer an encrypted connection, which is a solid and concrete improvement over a plain text transmission. Sure they are not signed by proper "authorities". Sure, there is the risk of a man in the middle attack. But you tell me which is more likely. Your encrypted login being intercepted by a man in the middle, or your unencrypted login being intercepted by a traffic sniffer?

The current hysterical warning Firefox throws up about self signed certs, which force users to run a gauntlet before they can use an encrypted channel are the sign of developers too concerned with internet commerce and cold war game theory to see the practical benefit of mass, cheap, encryption in this day and age. But given their tone and severe implementation, I find it difficult to believe that an open source development teams came to that decision on their own.

Firefox has single handedly set the secure web back five years. Instead of allowing the web and technology to evolve beyond its specifications, they stuck rigidly to RFC outlines made thirty years ago, and we are all suffering because of it.

Re:SSL is trying to do too much. (0)

Anonymous Coward | more than 4 years ago | (#29717729)

Without authentication someone can always eavesdrop using a man in the middle attack, this means that you can't have privacy without authentication .

This misconception that privacy and authentication are independent is one of the facts that several IT professionals gets wrong.

Re:SSL is trying to do too much. (1)

argent (18001) | more than 4 years ago | (#29718049)

Technically, you're correct. Technically, "this is the same site you visited the last time" is a very weak form of "authentication". Thing is, this is all the "authentication" most services need.

Re:SSL is trying to do too much. (1)

jcochran (309950) | more than 4 years ago | (#29718067)

It's not that simple.

Yes, without authentication, you can be subjected to a man in the middle attack.

However, that attack is an active one.

Without encryption, you can be subjected to a simple passive sniffing attack. Put a hub somewhere in the connection and sniff every packet that goes by. No need for an active attack. No need to establish two encrypted sessions (one to victim, one to victims intended destination). No need to interpret and alter packets going between the victim and destination.

Does encryption all by itself prevent all attacks? No it does not. Does it provide more protection than sending in the clear? Yes it does.

Re:SSL is trying to do too much. (1)

smoker2 (750216) | more than 4 years ago | (#29718265)

The main problem with "secure" sites is that too many people don't realise that the site is not what is secured. It is only the connection to the site that is encrypted, the server itself could be sitting in a room full of chinese hackers for all you know. Too many sites mention their "secure server" when in actual fact the machine is sat in a rack with thousands of other machines surrounded by minimum wage techs.

My open university course makes this mistake right at the beginning. It specifically says that "the letter 's' [appended to http] means you are connected to a secure web server, using techniques to protect your details from electronic snoopers". This is not true. Your precious credit card details could be sat on that server in plain text and you would be none the wiser.

Also, I have bought verified certs where the method of verification was an automated phone call to the number I gave in the application. What use is that ? I could be anyone, anywhere. So IMHO using certs for verification is a waste of time and gives entirely the wrong impression. Self signed certs are fine because they don't pretend to verify my identity, they just provide the details of who created them and encrypt the connection. If a 3rd party were to try phishing by creating their own self signed cert, the cached version in my browser tells me it is not valid because it has a different key. In this respect it is no different than a verified cert.

All the verification businesses go out of their way to avoid mentioning self signed certs, because they don't make them any money. But for the purpose for which they were designed, self signed certs are fine.

way out their (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#29717473)

With all the tools out their to manipulate SSL

Out their what?

Nevermind, I don't want to know.

Of course IT proffessionals don't get it (5, Insightful)

Malc (1751) | more than 4 years ago | (#29717521)

Have you ever tried teaching yourself the basics behind SSL, such as PKI and X.509 certificates? In an industry full of jargon and technalese, the security people are some of the worst for explaining things. The documentation out there is poor and cryptic. Ever wonder why encrypted or signed email never took off? Look no further than GnuPG or the Enigmail plug-in for Mozilla. Try finding out what DER encoding is, or ASC.1, or what PKCS#7 means. None of it's straight-forward, even for technical people.

Of course astronauts don't get it (1)

iYk6 (1425255) | more than 4 years ago | (#29718119)

Yeah. Prostitutes don't understand SSL either.

Slashdot has a weird definition of "pro". I figured it meant cryptography professionals. But if the title came out and said "IT professionals" or "lumber professionals" then it would be obvious that the story has no value.

Re:Of course IT proffessionals don't get it (2, Insightful)

Necroman (61604) | more than 4 years ago | (#29718293)

I'd like to second that motion. The same thing goes for encryption used for wireless routers. When a non-tech friend is setting up a new wireless router and is setting up the encryption part, they just see a list of 3 and 4 letter words they don't understand. And the only reason I know which is the best to pick is reading around the web to know which are easy to crack.

it's the browser implementation (4, Insightful)

circletimessquare (444983) | more than 4 years ago | (#29717551)

as the guy said in the article, it should kick you from a session at expired certs, not allow click through options

if the cert is expired/ unverifiable, the browser should simply kick the session, end of story

that should really be the only option available to anyone. its psychological: take this seriously, sorry for the inconvenience. otherwise, lazy admins will let their expired/ malformed certs hang out there for a lot longer (which i've seen even on a credit card site: capital one), because users just easily circumvent the roadblock. they'll definitely notice if no users can get through, and the angry emails pile in their inbox

i only allow https admin connections to my router, which of course means my browser screams about being unable to verify any certs... since i'm on a subnet. and i bet there are many other valid situations where expired/ unverified certs still represent a valid connection

however, add up all the valid situations where you want to continue an uncertified https connection, and you are left with nothing but a hill of beans in comparison to the mch more massive problem of psychologically just not taking https seriously enough

now you just have to convince the 3/4/5 major browser flavors to implement this new status quo

maybe the certificate authority should simply kick insecure browsers regardless (is that passed to the certificate authority during verification of cert?). that would get browser coders and vendors to notice. of course, what the browser report themselves can be hacked/ finessed, but if that's done maliciously, you're box is already owned, and its already game over regardless through a lot more powerful avenues

Re:it's the browser implementation (1)

Culture20 (968837) | more than 4 years ago | (#29717783)

Because people are going to ask:
Q: And what about self-signed where you can verify the cert's sig? Some applications only require half-arsed.
A: There obviously needs to be a workaround; either manual typing or pre-load it or your corporate CA's cert into company intranet browsers. Do something that _forces_ comparison of the sigs, not click click click (click click click click click click for FF3).

Re:it's the browser implementation (1)

tepples (727027) | more than 4 years ago | (#29717787)

it should kick you from a session at expired certs, not allow click through options

Given the following choices for a site that doesn't take credit cards:

  • A. Use a self-signed certificate for the password form
  • B. Do not use encryption on the password form
  • C. Take the site off the Web entirely

Which would you choose?

Re:it's the browser implementation (1)

Mr. Slippery (47854) | more than 4 years ago | (#29717815)

if the cert is expired/ unverifiable, the browser should simply kick the session, end of story

You can do that just as soon as CACert's free certificates [cacert.org] are recognized by the major browsers by default.

Re:it's the browser implementation (1)

Bigbutt (65939) | more than 4 years ago | (#29717857)

Java 1.6 Upgrade 15 through 18 does this. If you try to access a site with an invalid or expired cert, it just exits. Unfortunately it doesn't say why, it just exits so there are lots of lookups for WTF Java is doing, is my machine broken, or what? And you can't disable 15 and go back to 14 or earlier as it still bails. You have to uninstall 15 to gain access.

Of course the real problem is that we never updated the certs on our Dell Remote Access Consoles since it worked anyway. Since all the systems are inside the firewall and not accessible to the 'net, no one assigned any priority to taking care of replacing the Dell cert with a company one.

I'll have to see what the process is for getting a cert for the boxes, even if it's self signed.

[John]

Re:it's the browser implementation (1)

Lord Lode (1290856) | more than 4 years ago | (#29717867)

I think there are two separate things:
-having my password be encrypted on the LAN cables
-having a site being signed by a third party

For some reason, the first thing can't be done independently from the second. If I understood correctly, at least. Anyway, is there a possibility for websites to give you a secure line to them, without depending on a third party? I don't care about signing, but I care about sniffing on LAN cables.

Re:it's the browser implementation (1)

rgviza (1303161) | more than 4 years ago | (#29718077)

>as the guy said in the article, it should kick you from a session at expired certs, not allow click through options
>if the cert is expired/ unverifiable, the browser should simply kick the session, end of story

As long as that's a default setting you can override... Otherwise I have to have a valid paid cert on every one of my dev servers? F*** THAT.

wat (1)

Lord Ender (156273) | more than 4 years ago | (#29717609)

most of them are aware that SSL traffic can be sniffed without their knowledge.

You're doing it wrong.

Whoever wrote this article does not know what he's talking about.

Re:wat (1)

jafiwam (310805) | more than 4 years ago | (#29717947)

Well, it IS technically true it can be sniffed. It's just packets after all.

What the packets contain, on the other hand, won't be available to the person who now has them without a lengthy and large amount of computing power applied to it, plus a great deal of luck.

MITM attack on browser downloads (4, Interesting)

aembleton (324527) | more than 4 years ago | (#29717611)

With the exception of pre-installed machines, we all have to download our web browsers. What would stop someone carrying out a man in the middle attack on a web browser or distribution download that provided a different Firefox that contains different CA keys. These CA keys could be designed to work the same with https websites, but would allow a man in the middle to also read off the information being transmitted.

Admittedly this would be very hard to do, but theoretically possible and with the resources of a nation state this may have already been done. As most machines are now built in the far east, what would stop the IE that ships with your computer from also having altered CA keys?

Would it even be possible to detect this? You could use MD5 checksums on your downloads, but most of the websites that show an MD5 are unsecure, so they could easily be showing a manipulated version of the checksum.

This strikes me as one of the biggest flaws of our reliance on SSL v2, v3, whatever.

Please tell me that this isn't possible.

Re:MITM attack on browser downloads (1)

cenc (1310167) | more than 4 years ago | (#29717821)

Yes, and how do know that the browser that you originally installed with your operating system was not forged? How do you know your OS or your bios can be trusted? Hell, for that matter how do you know you can be trusted?

Ooooooohhh the horror!!!!

Not to be a troll, but you are really pushing that off in to fantasy land. My point it that security vulnerabilities based on 'just so' hypotheticals, are less likly to be a real world threat. Possible yes. Likely no.

Re:MITM attack on browser downloads (1)

aembleton (324527) | more than 4 years ago | (#29717911)

If you wanted to watch online banking transactions to a major bank like HSBC would this not be a way to do it?S ure, it would be difficult and would take a while, but you would gather huge amounts of information that is potentially worth millions.

The only difference between this and a completely unsecure connection is that it would take more effort and organisation and it would be limited to those browsers that you've set up a MITM attack for and have been downloaded. You could set up a MITM attack before a new release of a browser such as Firefox 4.0 and use a fake Verisign certificate.

This would only help you with listening to Firefox 4.0 connecting to https signed by Verisign; but this would be a way to gain access to bank accounts.

Re:MITM attack on browser downloads (0)

Anonymous Coward | more than 4 years ago | (#29717997)

You could use MD5 checksums on your downloads...

Which is a dead avenue anyways -- even in Ubuntu you can't just right-click for 'show MD5 checksum'. Most users will never use it.

Re:MITM attack on browser downloads (2, Interesting)

Nerdfest (867930) | more than 4 years ago | (#29718369)

That would be an excellent feature. Perhaps also an option to show it in the list of downloaded files automatically would be good.

Re:MITM attack on browser downloads (0)

Anonymous Coward | more than 4 years ago | (#29718055)

You can more or less verify that the software (browser, OS, etc) you just downloaded is the right one if the file is cryptographically signed by a key you know and trust to belong to the correct author.

Of course in practice you can't really be sure because:
  - is the public key you have the one that matches the real author's signing key? How do you know? Did you meet him/her in person and exchange keys, or did someone you trust do that and give them to you? Or, did you download the public key from some website and trust that it's "probably OK"?
  - did you audit the source code for your cryptographic program (GPG, or whatever) and compile it yourself, to know that it's not compromised?
  - did you audit the code for the OS you're running it on?
  - did you audit the source code for the compiler you used to build them both?

So all security online boils down to being "reasonably" confident that you're not being attacked. As to what's reasonable - that's up to each individual to decide, although if you're using the computer for nuclear weapons design for the government your bar for "reasonable" might be a bit higher than for someone to whom the computer is just a toy.

Re:MITM attack on browser downloads (1)

aembleton (324527) | more than 4 years ago | (#29718101)

Agreed. However, with more and more transactions moving online; surely the incentive is growing everyday for this kind of attack to occur.

Maybe for large scale theft, or maybe to have access to bank account that can be used for money laundering.

Re:MITM attack on browser downloads (1)

rgviza (1303161) | more than 4 years ago | (#29718281)

It's definitely possible. You can add CA's willy nilly to any install. This feature is present to allow companies to have self signed certificates used by their employees. You just need to have a server online that it contacts for the CA verification. You can check the list yourself and compare it to what it should be at:

http://www.microsoft.com/security/ [microsoft.com]

It will take some digging but it's in there. What's scary is that a hostile pc maker could replace the stock IE with their own that has hardcoded CA's which aren't visible by checking the list in IE... This would be tough to do though with the regular updates that MS does, unless they coded up a rootkit too, which hid the actual executibles from the update process and swapped the malware back in after the update.

Unlikely, but possible... The only way to be sure is to build your own PC and install "Genuine" media, which could be tampered with too, since it's packaged and printed overseas. Someone at Microsoft would catch on to that though, I hope.

Lack of education. (1)

miffo.swe (547642) | more than 4 years ago | (#29717719)

Personally i have thought about learning SSL from the ground up the "right way" countless times. The problem is finding a course thats general about implementation but dives down into the gritty details of SSL. I dont want to know howto meddle with SSL on a specifik product, i want to understand its inner workings so i can manage any implementation through good knowledge about wtf im doing.

Re:Lack of education. (1)

rgviza (1303161) | more than 4 years ago | (#29718405)

Or you could just install a free copy of VMWare server, a free linux distro, and install the free apache software with the free OpenSSL on it, then configure a virtual server, create a csr, process it to build the cert, install the cert and learn all about how it works using the documentation and How To's.

I'll give you a little hint though. Just remember that the certificate negotiation is done at the lower layers in the OSI model, so to have multiple certs on one server, you need to put each cert on it's own IP. It doesn't process the host request header til after the SSL connection is negotiated. Because of this you can't have a bunch of VHosts running SSL on the same IP. Only one will serve pages without a warning if you do... the exception being when all of the hosts are subdomains of the same domain, and you have a wildcard cert that's valid for all of the vhosts.

There's no better way to learn something than to do it, work through it and actually make it work ;)

Blogs, forums, and wikis (1)

tepples (727027) | more than 4 years ago | (#29717873)

From the article:

Reguly's survey found that while 83 percent of users check they're using an SSL-secured session before entering their credit card information on a Website, only 41 percent do so when typing in their passwords.

A lot of non-SSL password forms are on small blogs, forums, or wikis that don't handle financial data. Might the widespread lack of SSL on password pages have something to do with the price of a certificate for each such site?

Re:Blogs, forums, and wikis (1)

IBBoard (1128019) | more than 4 years ago | (#29718439)

That, and the fact that the free ones you can get (e.g. startssl.com, who I use) aren't automatically accepted. Not a problem for my webmail and admin sections, which are only used by me and my family, but far more annoying if I had a wider range of users hitting "WE CAN'T VERIFY THE CERTIFICATE CHAIN!!!!!" messages when all I want to do is put HTTPS on my site.

SSL is about trust. (1)

upuv (1201447) | more than 4 years ago | (#29718033)

SSL is all about trust in the end.

The monster problem is arrogant security people don't trust the other arrogant security people. Trust is implemented via certificates. EG I certify that this thing is what I say it is.

Problem. Who trusts the guy who gives out the certificate. Well as it turns out. Not many trust the other guys certificate. This leads to a problem. You can't build a pyramid of trust when you can't really trust the other guy.

So basically it makes it fairly impossible to create something like a local key store. I can't trust your key store because I can't trust the people that say your key store is a good one. Lets put this in terms people can understand. The government issues a locksmith with a certificate stating that this lock smith can hold copies of your home and safe keys. You can trust him because we the government trust him. Problem is no one trusts the government and no one believes that this guy actually has a real certificate. It could have been forged after all. So I'm not going to let him hold my precious keys.

So now I can't even trust my local key store. So just in case I'm going to add another level on top. I'm going to add a pass phrase. This is something I need to repeat every time I need to do something special involving security. Like say open a door. I turn the key and utter my pass phrase.

Again we got a problem. I have doubts about the pass phrase. Someone might have recorded the pass phrase and is able to play it back after they have used a dodgy copy of my key.

So in the end the trust chain is very fragile. Just one little bit of doubt in the system and it all falls down. This is what has happened. Due to now decades of mistrust of the trust systems layers and layers of paranoia trust have been piled on. And those too have suffered mistrust. So now you have this massive mess of mis-trusted trust and as a result security has broken down. Or rather it has never built up.

---
Basically I have given up all hope that certificate authorities can give me something that is trust worthy and future proof. Simply because they don't like to talk to each other and subsequently they under mine each others public trust. My business is private in that I deal with a customer at a time.

I issue my own private certs and ask them to accept them. They pay me for a service. The contract they sign with me puts legal consequences around the violation of trust of our financial agreement. Thus I simply state this contract is the legal trust you require. If you trust the contract your trust my certificate. In most cases the contract is less expensive than buying a cert. Everyone wins and we actually have a contract of trust. I make more money and they customer pays less. Of course this model doesn't apply to strangers dealing with strangers but it works great for me.

Pick me, pick me! (0)

Anonymous Coward | more than 4 years ago | (#29718421)

I know how to what SSL is! Fo' real!

Look at Scottrade (0)

Anonymous Coward | more than 4 years ago | (#29718431)

It's an HTTP page, but they put a *picture* of a padlock in the middle of the page, so you know it's "ok" to login. And millions of people just go ahead and login from that page.

http://www.scottrade.com/ [scottrade.com]

(Yes, I know the login does go to an HTTPS server. But it's the general idea that counts).

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

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>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...