-1

I was wondering about HTTPS security and how easily is compromised. I have already read the similar threads in here, but I have some more questions:

  1. Let's say I am searching something at Google. Supposing I have a malware-free machine(but dont know if someone monitors my wire), who can view those data? Google? The Goverment? The ISP?

  2. If someone monitors the https handshake with Google, can it export useful/ private information?

  3. Is it trivial to break on a certification authority to fool it, and fool https too? As far as I know, cryptographic attacks have not that luck against HTTPS

Waiting for your feedback :)

py_script
  • 781
  • 2
  • 7
  • 10
  • 2
    This question is too broad for an answer here. There's just too much to cover. I've voted to close it. Please have a look around here and you'll find that your questions have been answered many times here. – Adi Jun 09 '13 at 12:09
  • 2
    Here are some things you need to read: http://security.stackexchange.com/q/6290/ - http://security.stackexchange.com/q/24493/ - http://security.stackexchange.com/q/37076/ - http://security.stackexchange.com/q/16971/ - http://security.stackexchange.com/q/12041/ - http://security.stackexchange.com/q/5/ - http://security.stackexchange.com/q/6778/ – Adi Jun 09 '13 at 12:22
  • 1
    @Adnan Y U NO use markdown syntax `[Q1](http://example.com)` – HamZa Jun 09 '13 at 13:19
  • 2
    @HamZa Because it requires more effort. – Adi Jun 09 '13 at 13:58

1 Answers1

2

1) Assuming that the server is also malware free, and that you aren't subject to a Man in the Middle (MitM) attack, only the client and the server can monitor the connection. It's easy to see how the session can be monitored if client or server is compromised. MitM is the real attack vector against this.

With MitM, the attacker presents the client with a certificate that purports to be the server's. The attacker effectively proxies the client's requests. This does require that the client either accept a certificate warning, the attacker has attacked a certificate authority and has fraudulently issued a legitimate SSL cert to his or herself, or that the attacker has control over DNS from the client to bypass the security checks a browser does on an SSL certificate.

2) If one monitors the handshake, and knows (or can cryptographically attack) the private key used to establish the session key for the connection, one can decrypt the SSL session. Wireshark, for example, is able to do this out of the box.

3) Successfully attacking the CA is going to get you a valid certificate for a domain of your choice. Comodo was attacked a year or so ago, and issued some bad certs for Google. This is not required to successfully attack a connection, though.

As mentioned, one can man in the middle. There have been protocol vulnerabilities in SSL1 and SSL2 that allow cryptographic attacks. The current iteration of TLS is good, as far as we know, but it is an area of crypto research. Additionally, the SSL handshake negotiates the algorithm used for encryption. Multiple weak encryption algorithms are enabled by default (there's actually a null cipher suite that does no encryption!), and if used can compromise the confidentiality of your connection.

  • 1) Does the ISP logging(as commanded by several laws) considered MiTM attack(in results perspective)? For example in EU, ISPS are obligated to keep logs of internet activity i.e urls visited, for two years. Can they actually see what I am searching in Google, as soon as it a secured connection? – py_script Jun 09 '13 at 14:44
  • 1
    To directly answer, no. They'll know you're talking to Google, but not what you're talking about (unless you click through on google to an insecure site and your referrer field leaks info). However, if your browsing information is being collected under warrant all bets are off. – Brandon Franklin Jun 09 '13 at 14:49
  • you missed off good sslstrip attacks, who cares about encryption when the browser will even connect just fine without it. And most users wouldn't notice. – ewanm89 Jun 09 '13 at 14:56