Because you are vulnerable to man in the middle on a transparent proxy in your company's network. This is why we have trusted certificate chains - so that we can verify who we're talking to with a piece of knowledge we already hold - the issuing authority's public key.
You'd still need to have obtained the private key of whatever org we're talking about, if you want to pretend to be (for instance) hsbc.co.uk, you'd still need to have a certificate that my browser would accept, and in that name.
That's kinda where his objections fall down. Verisign haven't been handing out dodgy certificates in other people's names wholesale. Sure, anyone can get a cert from them, but there is *some* requirement to at least prove ownership of the domain it's for.
"The only thing it does is to assure you that the bank says they are who Verisign says they are. Equating that to the bank actually being who they say they are, requires infinite trust in Verisign and their honesty."
Not really. Not "infinite". It simply says you trust verisign to give these things out, and so does your bank. Otherwise they wouldn't have one.
You're right, all the assurance you have is that verisign say that you're talking to who you think you are. And that's enough, provided they don't deliberately mis-sell certificates.
"If I'm the victim of a MITM-attack, why would I even care if Verisign says that the attacker is my bank or not? He's still going to copy the entire encrypted transactions either way."
Umm, if you're the victim then it's already too late. The idea is to prevent MITM attacks from being possible. If the MITM has somehow got hold of a way of -
a) Poisoning your DNS b) Getting hold of a signed, trusted certificate in the name of your bank.
Then that's what the bank's insurance is for, they've been severely compromised at this point.
The MITM has to somehow determine whether the client knows the root cert or not."
Nope. Not necessarily, if we take an opportunistic approach.
I have an incoming server certificate.
a) Is it something I have signed with the stuff I have access to? OK, we'll sign a new one and snoop. b) Is it something signed by someone else? OK, well I'll take a gamble and create a CA and server certificate using the details from the incoming server certificate.
This stuf is fairly trivial to implement by the way. Thanks openssl:)
You end up with four scenarios -
1) Client talks to internal trusted system that our snooper has access to the keys for - MITM is possible and invisible.
2) Client talks to external trusted system that our snooper does not have access to keys for. Client does not have server public certificate - MITM is possible and invisible using opportunistic certificate creation. You're expecting the popup and the certificate details are the same.
3) Client talks to external trusted system for which it has the trusted certificate - MITM requires client to accept your dodgy cert.
This becomes even more insidious if we add a rule 3 to our opportunistic snooper -
c) Was it signed by a recognised public CA? Then I'll leave it alone.
Now you have no idea, your system works the same way whether our snooper is there or not, but he gets to listen in on your communications if you're talking to stuff he controls, or if you're talking to unverified, non-mainstream certificates.
The only way to catch him at it is to use verified non-mainstream certificates.
I'm sorry, but your little "This cert isn't trusted" box is not giving you the assurance you think it is.
"If someone at work (who controls the browser, the proxy, the network etc) decided to sniff all SSL traffic - which they could do with a MITM attack because they control at least one of the allowed root certs in the browser - my popup would disappear (unless they were very careful)
Likewise, my mail servers all use self signed certificates. Again, someone trying to attack me by getting verisign (or whoever) to sign a certificate, will not work.
Self signed certificates don't prevent attacks but they do mean that the attack cannot easily be automated."
Umm. No.
These attacks can be very very easily automated.
1 - Spot SSL connection and become a proxy. 2 - When server sends certificate, read all the fields and create new certificate with identical ones but a different public/private key pair. 3 - sign this with a random, and still unknown CA 4 - Send this new one on to the client. You now have two SSL sessions going, and the client doesn't have a clue what happened.
Your popup stays and looks the same (unless you're into reading the public key). Your traffic is all being logged and read.
Solution - take your public key/certificate from home and put it into your browser at work. Otherwise you have absolutely zero protection from snooping.
"It's swings and roundabouts. Verisign et al have built a whole industry out of convincing people to trust them more than the person's own bank."
No, they haven't. They've built a business out of having their root certificates in everyone's browser, and being fairly reliable at verifying that the server you are talking to is owned by the same guy they sold the certificate too. That is all they do.
Your bank could easily become its own CA, all it would need to do is send out a CD with it's public key to its customers. But then you have distribution issues and all sorts of other things....
"I am talking about encrypting my packets to some kind intranet or webmail which ensures me that nosy admins or kids who are trying to read packets in a public WIFI couldn't read my private messages with ease"
A self signed certificate does not give you this protection.
Public wifi is a great example. If you're going to accept a self signed certificate then you might be talking to anyone. I could really really easily put something on my wireless router's firmware to detect SSL connections and be a man in the middle. All that happens is that it becomes transparent proxy and it creates a new, self signed certificate, telling you that it's the site you're trying to connect to.
A nosy admin could set this up easily. If you haven't got the authentication aspect (which is why things are signed) then you don't have any guarantee that your encrypted packets are going where you think they are and being decrypted by who you think is decrypting them.
Now, there's no reason not to have an in-house or private CA for your systems, so you don't pay Verisign or Thawte or whoever, but you should always distribute the trusted private key for the CA beforehand.
For the billionth time - If there isn't either 3rd party authentication or a certificate esxchange done via on offline method then you are vulnerable to a man in the middle attack if you accept self signed certificates.
A self signed certificate absolutely does detract from security. It means that anyone can do a man in the middle attack and see exactly what's going on.
"SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate."
This is one of the most stupid things I've read all year and clearly comes from someone that knows absolutely FUCK ALL about SSL/TLS.
SSL certificates provide authentication that the server you are talking to is the one the certificate was issued to. They provide you with a level of trust. Not absolute trust, but they tell you this one thing -
The person I think I'm talking to, the CA agrees that it's them.
SSL certificates do NOT provide encryption. Asymmetric encryption is computationally expensive. In SOME SSL/TLS cipher suites they may provide a key exchange mechanism. However this is not always the case and we have Diffie-Hellman (DH and DHE) style shared-secret mechanisms for that. AES or 3DES are most often used for the actual encryption. SSL/TLS also provides for data integrity checking using MD5 or SHA hashes. You don't have to have encryption at all, in some circumstances the authentication and integrity are what you're after.
Anyway, I just thought I'd point out that your post there is fucking nonsense.
"In order to hose you, all I need to do is direct your browser to a new IP where I have a server set up to respond as www.google.com, with a certificate to match which I got from my brother, who works at google, or my sister, who quietly and non-destructively (she's too smart to be interested in showing she's been there) got root on some of google's https-delivery hardware."
Right, so by this time, you've not only compromised my ISP DNS servers or my home computer, but you've compromised Google as well.
If you have access to all these systems then why the fuck do you care about SSL?
This is non-trivial and a highly organised criminal gang like the one you're part of is not the problem SSL is trying to fix.
But there you're solving a completely different problem!
The SSL certificate scheme is there to assure your browser (you) that the bank is who they say they are.
The electronic pad and/or card are there to assure the bank that you are who you say you are.
Completely different problems. Without the first being solved (usually via SSL) then you have no idea who you're giving your username, password and one-time number to.
IMHO this is a MAJOR problem in security. Most people don't understand that there are multiple different issues of trust, secrecy and integrity to be solved in any given situation.
"If you learned C (as I did) you're lost in today's C++, C#, Objective C world."
That's my point, it may seem like that's our world, but it isn't our world at all. In today's world you're just as well off knowing C. Things don't move on that fast and C is still the number two language. Personally I learned and have commercial experience of a variety of languages, but C is the one I'm most comfortable with.
"Further, who says programming languages are all that make up CS?"
Nobody. Which is why I mentioned that computer architecture is not shifting paradigms particularly quickly, and that efficiency of data structures and algorithms is effectively a mathematical field.
Doing things yourself often engenders a deeper understanding of what is going on. My real aim was familiarity with the TDS protocol, which I gained.
Thanks though, next time I just want to do something quickly without learning anything at all I'll use this new "google" thing you seem to have discovered.
The second most popular language in industry after java (itself not exactly a spring chicken) is C. which has been with us since the 70s.
Couple that with the theory of the underlying machines being roughly the same (though undergoing constant enhancement), the theory behind efficiency in data structures and algorithms being effectively a mathematical exercise, and language skills being very transferable.
Compputer science is nowhere near as dynamic as your perception of it, nor is it removed from every day use. It is a science, there is also the related engineering discipline (Software Engineering), in which people like me (a CS grad in a typical job that CS grads end up in) apply their knowledge of computer science to real programming.
A good course should teach you a decent amount of both.
"...intercourse is meant to be an act performed in private for the two parties that love and care for each other..."
That's your interpretation. It's not everyone's by any means.
Ask most men in their early 20s and you'll find that intercourse is an act performed wherever and whenever they can get away with it with whoever is looking good that day.
Ask a lot of young women of today and they'll tell you much the same (though probably a little less extreme).
Ask polyamourists, swingers, exhibitionists etc, you'll get a different answer every time.
What's "meant to be", that depends on who you ask. To me it sounds like a religious proclamation.
this is not to say I want to see fat people screwing in the streets, just that not everyone thinks the way you do.
I'm guessing that means "if our customers find out the crap we're pulling then they'll go to the competition".
Either that or that competitors will realise exactly how much it's possible to dupe their customers into acxcepting as "just the way it is" before anyone gets upset.
Slashdot Mirror
"The MITM can add root certs to the client"
You're right, I did miss the part where you said they control the browser.
If they control the browser then you're already shafted.
No it won't
And do you know why?
Because you are vulnerable to man in the middle on a transparent proxy in your company's network. This is why we have trusted certificate chains - so that we can verify who we're talking to with a piece of knowledge we already hold - the issuing authority's public key.
You'd still need to have obtained the private key of whatever org we're talking about, if you want to pretend to be (for instance) hsbc.co.uk, you'd still need to have a certificate that my browser would accept, and in that name.
That's kinda where his objections fall down. Verisign haven't been handing out dodgy certificates in other people's names wholesale. Sure, anyone can get a cert from them, but there is *some* requirement to at least prove ownership of the domain it's for.
"The only thing it does is to assure you that the bank says they are who Verisign says they are. Equating that to the bank actually being who they say they are, requires infinite trust in Verisign and their honesty."
Not really. Not "infinite". It simply says you trust verisign to give these things out, and so does your bank. Otherwise they wouldn't have one.
You're right, all the assurance you have is that verisign say that you're talking to who you think you are. And that's enough, provided they don't deliberately mis-sell certificates.
"If I'm the victim of a MITM-attack, why would I even care if Verisign says that the attacker is my bank or not? He's still going to copy the entire encrypted transactions either way."
Umm, if you're the victim then it's already too late. The idea is to prevent MITM attacks from being possible. If the MITM has somehow got hold of a way of -
a) Poisoning your DNS
b) Getting hold of a signed, trusted certificate in the name of your bank.
Then that's what the bank's insurance is for, they've been severely compromised at this point.
Three! I meant three scenarios!
"I disagree.
The MITM has to somehow determine whether the client knows the root cert or not."
Nope. Not necessarily, if we take an opportunistic approach.
I have an incoming server certificate.
a) Is it something I have signed with the stuff I have access to? OK, we'll sign a new one and snoop.
b) Is it something signed by someone else? OK, well I'll take a gamble and create a CA and server certificate using the details from the incoming server certificate.
This stuf is fairly trivial to implement by the way. Thanks openssl :)
You end up with four scenarios -
1) Client talks to internal trusted system that our snooper has access to the keys for - MITM is possible and invisible.
2) Client talks to external trusted system that our snooper does not have access to keys for. Client does not have server public certificate - MITM is possible and invisible using opportunistic certificate creation. You're expecting the popup and the certificate details are the same.
3) Client talks to external trusted system for which it has the trusted certificate - MITM requires client to accept your dodgy cert.
This becomes even more insidious if we add a rule 3 to our opportunistic snooper -
c) Was it signed by a recognised public CA? Then I'll leave it alone.
Now you have no idea, your system works the same way whether our snooper is there or not, but he gets to listen in on your communications if you're talking to stuff he controls, or if you're talking to unverified, non-mainstream certificates.
The only way to catch him at it is to use verified non-mainstream certificates.
I'm sorry, but your little "This cert isn't trusted" box is not giving you the assurance you think it is.
Well, the best way to go about it is to set up your own signing authority at home. This is really easy with openssl and/or the gnu TLS suff.
Then you sign your webmail server with it and import your own public key from the CA into your browser.
Viola - you have secure, authenticated SSL without paying anyone else a penny :)
"If someone at work (who controls the browser, the proxy, the network etc) decided to sniff all SSL traffic - which they could do with a MITM attack because they control at least one of the allowed root certs in the browser - my popup would disappear (unless they were very careful)
Likewise, my mail servers all use self signed certificates. Again, someone trying to attack me by getting verisign (or whoever) to sign a certificate, will not work.
Self signed certificates don't prevent attacks but they do mean that the attack cannot easily be automated."
Umm. No.
These attacks can be very very easily automated.
1 - Spot SSL connection and become a proxy.
2 - When server sends certificate, read all the fields and create new certificate with identical ones but a different public/private key pair.
3 - sign this with a random, and still unknown CA
4 - Send this new one on to the client. You now have two SSL sessions going, and the client doesn't have a clue what happened.
Your popup stays and looks the same (unless you're into reading the public key). Your traffic is all being logged and read.
Solution - take your public key/certificate from home and put it into your browser at work. Otherwise you have absolutely zero protection from snooping.
"It's swings and roundabouts. Verisign et al have built a whole industry out of convincing people to trust them more than the person's own bank."
No, they haven't. They've built a business out of having their root certificates in everyone's browser, and being fairly reliable at verifying that the server you are talking to is owned by the same guy they sold the certificate too. That is all they do.
Your bank could easily become its own CA, all it would need to do is send out a CD with it's public key to its customers. But then you have distribution issues and all sorts of other things....
Again, you've missed the point.
"I am talking about encrypting my packets to some kind intranet or webmail which ensures me that nosy admins or kids who are trying to read packets in a public WIFI couldn't read my private messages with ease"
A self signed certificate does not give you this protection.
Public wifi is a great example. If you're going to accept a self signed certificate then you might be talking to anyone. I could really really easily put something on my wireless router's firmware to detect SSL connections and be a man in the middle. All that happens is that it becomes transparent proxy and it creates a new, self signed certificate, telling you that it's the site you're trying to connect to.
A nosy admin could set this up easily. If you haven't got the authentication aspect (which is why things are signed) then you don't have any guarantee that your encrypted packets are going where you think they are and being decrypted by who you think is decrypting them.
Now, there's no reason not to have an in-house or private CA for your systems, so you don't pay Verisign or Thawte or whoever, but you should always distribute the trusted private key for the CA beforehand.
For the billionth time - If there isn't either 3rd party authentication or a certificate esxchange done via on offline method then you are vulnerable to a man in the middle attack if you accept self signed certificates.
A self signed certificate absolutely does detract from security. It means that anyone can do a man in the middle attack and see exactly what's going on.
"SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate."
This is one of the most stupid things I've read all year and clearly comes from someone that knows absolutely FUCK ALL about SSL/TLS.
SSL certificates provide authentication that the server you are talking to is the one the certificate was issued to. They provide you with a level of trust. Not absolute trust, but they tell you this one thing -
The person I think I'm talking to, the CA agrees that it's them.
SSL certificates do NOT provide encryption. Asymmetric encryption is computationally expensive. In SOME SSL/TLS cipher suites they may provide a key exchange mechanism. However this is not always the case and we have Diffie-Hellman (DH and DHE) style shared-secret mechanisms for that. AES or 3DES are most often used for the actual encryption. SSL/TLS also provides for data integrity checking using MD5 or SHA hashes. You don't have to have encryption at all, in some circumstances the authentication and integrity are what you're after.
Anyway, I just thought I'd point out that your post there is fucking nonsense.
"In order to hose you, all I need to do is direct your browser to a new IP where I have a server set up to respond as www.google.com, with a certificate to match which I got from my brother, who works at google, or my sister, who quietly and non-destructively (she's too smart to be interested in showing she's been there) got root on some of google's https-delivery hardware."
Right, so by this time, you've not only compromised my ISP DNS servers or my home computer, but you've compromised Google as well.
If you have access to all these systems then why the fuck do you care about SSL?
This is non-trivial and a highly organised criminal gang like the one you're part of is not the problem SSL is trying to fix.
Right, so the problem is user stupidity and education, not SSL.
But there you're solving a completely different problem!
The SSL certificate scheme is there to assure your browser (you) that the bank is who they say they are.
The electronic pad and/or card are there to assure the bank that you are who you say you are.
Completely different problems. Without the first being solved (usually via SSL) then you have no idea who you're giving your username, password and one-time number to.
IMHO this is a MAJOR problem in security. Most people don't understand that there are multiple different issues of trust, secrecy and integrity to be solved in any given situation.
"If you learned C (as I did) you're lost in today's C++, C#, Objective C world."
That's my point, it may seem like that's our world, but it isn't our world at all. In today's world you're just as well off knowing C. Things don't move on that fast and C is still the number two language. Personally I learned and have commercial experience of a variety of languages, but C is the one I'm most comfortable with.
"Further, who says programming languages are all that make up CS?"
Nobody. Which is why I mentioned that computer architecture is not shifting paradigms particularly quickly, and that efficiency of data structures and algorithms is effectively a mathematical field.
Learn to read.
Doing things yourself often engenders a deeper understanding of what is going on. My real aim was familiarity with the TDS protocol, which I gained.
Thanks though, next time I just want to do something quickly without learning anything at all I'll use this new "google" thing you seem to have discovered.
Utter rot.
The second most popular language in industry after java (itself not exactly a spring chicken) is C. which has been with us since the 70s.
Couple that with the theory of the underlying machines being roughly the same (though undergoing constant enhancement), the theory behind efficiency in data structures and algorithms being effectively a mathematical exercise, and language skills being very transferable.
Compputer science is nowhere near as dynamic as your perception of it, nor is it removed from every day use. It is a science, there is also the related engineering discipline (Software Engineering), in which people like me (a CS grad in a typical job that CS grads end up in) apply their knowledge of computer science to real programming.
A good course should teach you a decent amount of both.
Wow, vbscript huh?
Hardcore...
"Last week I setup our exchange server to output some data to a database"
Last week I spent some time optimising the SQL analyser in our in-memory database and wrote an SSL protocol decoder in my spare time.
True, but it looks like we love a good fish supper even more:
http://www.google.com/trends?q=fish%2C+tea&ctab=0&geo=GB&geor=all&date=all&sort=1
Well, I don't know where the line should be drawn or even if there should be a line, frankly but I don't really want to see that...
"...intercourse is meant to be an act performed in private for the two parties that love and care for each other..."
That's your interpretation. It's not everyone's by any means.
Ask most men in their early 20s and you'll find that intercourse is an act performed wherever and whenever they can get away with it with whoever is looking good that day.
Ask a lot of young women of today and they'll tell you much the same (though probably a little less extreme).
Ask polyamourists, swingers, exhibitionists etc, you'll get a different answer every time.
What's "meant to be", that depends on who you ask. To me it sounds like a religious proclamation.
this is not to say I want to see fat people screwing in the streets, just that not everyone thinks the way you do.
I'm guessing that means "if our customers find out the crap we're pulling then they'll go to the competition".
Either that or that competitors will realise exactly how much it's possible to dupe their customers into acxcepting as "just the way it is" before anyone gets upset.
He's just gone into the future to the time when the Wyld Stallyns music forms the basis of society.
Darth Vader is trying to buy uranium from unwed dope smoking teenagers.
There, now I think we have all the bases covered :)