Sign up ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sorry for the inconvenience, as English is not my native.

I use hosts to access some websites as DNS is polluted.

My question is, take as an example.

If I am successfully social engineered by an attacker, and changes the translation in hosts into a phishing website.

If I use http, then I am completely screwed, right?

If I use https, then the browser will give a warning, if my PC is not compromised.

For the https case, is it possible that the phishing website just pass a certificate from to me to prove it is genuine?

share|improve this question
Are you the IT support guy maintaining your bank's website? cheated into assigning the domain to the IP of a phishing website? Makes no sense. And what do you mean "Assign IPs directly via hosts in windows"? All that normally means is manually or via DHCP. your question doesn't make much sense. –  barlop Jul 25 '11 at 11:08
If you mean your hosts file got used, that's not called assigning IPs, it's translating. Your question is garbage. Look at your hosts file make sure it's ok. –  barlop Jul 25 '11 at 11:09
you should try to reword your question. you know what you mean. –  barlop Jul 25 '11 at 11:09
you did a good editing job there –  barlop Jul 25 '11 at 13:50

3 Answers 3

up vote 4 down vote accepted

Consider the following statements:

  • All certificate authorities trusted by your web browser refuse to issue a certificate for to the attacker without proof of domain ownership.

  • The signing keys of all authorities are securely stored and an unauthorized person cannot issue a certificate to themselves. (See recent Comodo break-in.)

  • Your web browser correctly checks if the server's SSL certificate is issued by a valid CA, not revoked, valid for use by servers, and issued for the domain.

  • There is no active malware or a browser bug that causes such checks to be bypassed.

  • You always open, requesting SSL explicitly instead of relying for the website to redirect you.

  • You actually read the SSL error messages instead of blindly clicking Ignore when you open the website.

If all of the above are true, HTTPS will warn you that you tried to connect to a fake website. However, HTTPS cannot bypass lower-level redirections (such as spoofing by DNS or /etc/hosts), so if you ignore the warnings, your data will be going to the attacker, not to the real bank.

To conclude, yes, it's dangerous.

In response to the edited question:

  1. If you use plain HTTP, you're screwed.

  2. If you use HTTPS, you will receive a big red warning (see first part of the answer).

  3. Every "certificate" has a RSA (sometimes DSA, ECDSA) key pair. The public key of the pair is part of the certificate, while the private key is locked away in the webserver and never sent over the network. Both keys are needed to successfully complete the TLS/SSL handshake.

    If the attacker presents a certificate, but does not have the associated private key, they will not be able to decrypt any traffic that goes over TLS. Wikipedia has a description of the TLS handshake.

share|improve this answer
Thank you. You almost answered my question. But as requested by the comments, I edited my question. Would you kindly have a look, and answer the edited questions. –  user69835 Jul 25 '11 at 11:22
@Dante: See update. –  grawity Jul 25 '11 at 11:51

SSL (HTTPS) will only protect you as long as your client is not compromised.

If someone manages to modify /etc/hosts, he can also manage to modify your browser to not perform the SSL validation of the server you're connecting to, or he can add his fraud server's fake certificate into your system's database of trusted certificates.

If however your client is not compromised and someone manages to redirect your browser to a different IP address (e.g. some kind of DNS-related hack, or cheating you to modify /etc/hosts without anything else), the browser will warn you that something's wrong with the server's certificate, and, provided you don't ignore the warning and proceed, you are safe.

On your second question:

For the https case, is it possible that the phishing website just pass a certificate from to me to prove it is genuine?

No, that is not possible, unless the attacker managed to obtain the server's private key (e.g. by hacking the server itself). Even if a fraud server "passed on" the server's certificate, he will not be able to prove its identity to the client if it does not possess that private key. If he attempted to do that, he will fail and the browser will show a warning.

share|improve this answer
Thank you. You answer is also good. But as requested by the comments, I edited my question. Would you kindly have a look, and answer the last question? –  user69835 Jul 25 '11 at 11:23

Dante, your edits are welcomed. But the answer remains. If the hosts file is compromised, your whole security can be compromised concerning those domains that have been socially engineered on that file.

HTTPS is the exception and will offer some form of protection due to the certificate system that will let you know the website you are viewing may not be what it seems.

share|improve this answer
So no matter what they do, as long as only IP is wrong, HTTPS will cause a warning, right? –  user69835 Jul 25 '11 at 11:42
To the extent of my knowledge, yes. You should accept any of the two other answers. I only answered here because the question comment area has been polluted by other remarks. –  A Dwarf Jul 25 '11 at 11:44
Wrong. HTTPS only protects against a "man-in-the-middle" attack. That's to say, an attacker that doesn't alter either your web browser or the web server, but one that does control some part of the network in the middle (e.g. the WiFi). If the Hosts file is compromised, the attacker has succesfully breached the client security, and no longer can be classed as man-in-the-middle. He can equally well replace your browser with one that skips all HTTPS. checks –  MSalters Jul 26 '11 at 10:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.