|
2014-01-30
, 10:36
|
|
Posts: 1,974 |
Thanked: 1,834 times |
Joined on Mar 2013
@ india
|
#2
|
|
2014-01-30
, 10:38
|
|
Posts: 7,075 |
Thanked: 9,073 times |
Joined on Oct 2009
@ Moon! It's not the East or the West side... it's the Dark Side
|
#3
|
|
2014-01-30
, 19:37
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#4
|
Of course, if you are the US gov, and you have forced google.com to just hand over their SSL private keys, you can just decrypt any SSL sessions for which you have packet captures. (Also another tool that corporate IT security departments use to protect their own web servers; SSL decryption and inspection at wire speeds.)
joerg@saturn:~> openssl s_client -connect wiki.maemo.org:443
...
Cipher : DHE-RSA-AES256-GCM-SHA384
|
2014-01-31
, 02:49
|
Posts: 254 |
Thanked: 509 times |
Joined on Nov 2011
@ Canada
|
#5
|
Err, see (EC)DHE and PFS aka "perfect forward secrecy" - it happens that google actually does use PFS
http://stackoverflow.com/questions/1...orward-secrecy
And no, your company's security team implements true MITM on your gateway to do SSL inspection, which nevertheless usually needs you to accept resp install the company's own root cert to your list of trusted certs.
The Following User Says Thank You to shawnjefferson For This Useful Post: | ||
|
2014-02-07
, 07:57
|
Posts: 89 |
Thanked: 194 times |
Joined on Feb 2010
|
#6
|
The operator or ISP can certainly man-in-the-middle your DNS queries (most of the time your using their DNS servers) and deliver whatever IP address they feel like for any name you request. Some do exactly that for non-existent domain names for instance instead of a NXDOMAIN record. There's a high level of trust you have to have in your DNS servers.
But with a secure site (https), there are a couple of mechanisms that should tip the user off if someone is trying to spoof a site, and also several layers of trust.
1. Your browser is going to check that the certificate matches the dns name of the server you are requesting a session with.
2. The browser is going to verify that the certificate is trusted by your browser (ie. is signed by one of the trusted CAs.) These Certificate Authorities are trusted to not sign fraudulent certificates, nor provide certificates to people who do not own those domains. (Once in a while this trust level breaks down, due to these CAs being hacked, and then the CAs certificate gets revoked.)
If those checks don't succeed, you should get a message from the browser that something is wrong with the certificate and if you continue, you're taking a risk.
There's really only a couple of ways that I'm aware of that a secure site can be successfully spoofed:
- A trusted CA is hacked into and a certificate signed for whichever domain name the attacker is trying to spoof and then this certificate is used in the attack.
- Somehow the attacker gets their own CA certificate into your trusted CA list on your computer/browser. This is how in corporate environments SSL sessions can be monitored by corporate proxies. If you own all the endpoints, you can install your own trusted CA certificates and the browser is quite happy with that.
Of course, if you are the US gov, and you have forced google.com to just hand over their SSL private keys, you can just decrypt any SSL sessions for which you have packet captures. (Also another tool that corporate IT security departments use to protect their own web servers; SSL decryption and inspection at wire speeds.)