Wikipedia:Reference desk/Archives/Computing/2018 May 3
Computing desk | ||
---|---|---|
< May 2 | << Apr | May | Jun >> | May 4 > |
Welcome to the Wikipedia Computing Reference Desk Archives |
---|
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
May 3
editIs a proxy website a "man-in-the-middle"?
editIf you use a free proxy website to access another website does that mean that the proxy website can log anything you type into the accessed website? 129.215.47.59 (talk) 11:59, 3 May 2018 (UTC)
- Yes, it can. That doesn't mean it does. The man-in-the-middle is specifically used for bypassing TLS authentication. But, to generalize it to what you are discussing, you send a plain text request to the proxy. The proxy forwards that plain text request to the server. Obviously, the proxy knows your IP address and the request. It can be logged. When the reply comes back from the server, the proxy knows the reply and your IP address - that is how it knows to send it to you. So, it can log that as well. You have no way to know if it has been logged. The next step is discussing TLS. In that scenario, you use a private/public key pair. You send the public key to the proxy. The proxy SHOULD send that public key to the server. Then, the server sends it's public key to the proxy and the proxy SHOULD send the server's public key to you. You can use a certificate authority to verify that the public key from the server is actually the server's public key. If it is, the the proxy is unable to know the content of what is being requested or received in real time. Technically, it could hack it eventually, but that isn't realistic. There is a real problem for a man-in-the-middle attack here. What if the public key you got from the proxy is not the server's real public key? That is happening more and more with corporate networks. That means that the proxy didn't forward your public key to the server. It sent it's own public key to the server. Then, it sent you the proxy's public key. The proxy is decrypting all traffic. It is encrypted between you and the proxy. It is encrypted between the proxy and the server. It is decrypted on the proxy itself. So, it can be logged. To hide this from you, it is common for networks (physical or proxy) to ask you to install a mod to your certificate authority settings. For example, BuyNLarge might have all of it's company computers automatically trust certificates signed by buynlarge.com. You go to your bank's website, boa.com. You should get a certificate for boa.com. You don't. You get a certificate for boa.buynlarge.com. The mod on your computer says that certificate is completely valid. You get no warning that the company is decrypting everything and, likely, logging it. Proxies do that. Companies do that. Universities do that. Assholes in a truck sitting in the Holiday Inn parking lot with a wireless access point named "RealHolidayInnNetwork" are doing it. We are back to the point that "secure" is just a feeling. Your data isn't really secure. 209.149.113.5 (talk) 12:24, 3 May 2018 (UTC)
- Network proxies are capable of man-in-the-middle attacks; but they would need to spoof or circumvent some difficult technologies. Other software is also capable of a man-in-the-middle attack too - and by selecting targets other than the encryption algorithms that protect the network-data-transport layer, those attacks are simpler to execute.
- In my estimation, "secure" software has been largely replaced by "software with a user-interface or logo that conditionally shows some type of security icon." I find it abjectly comical that drawing a "lock" icon in a web browser makes people believe that their otherwise-unspecified implementation details all correctly and completely conform to some amorphous concept of generally-agreed-upon best practices.
- Think of it this way: any software that can draw pictures to your screen is capable of drawing a picture of some other securely-implemented software; this is a great place to execute a man-in-the-middle attack. For all you know, even your operating system is just a piece of malware that is designed to draw pictures that look like a secure operating system, unless you intentionally hand over the private key to your trusted vendor. You know, that major software and computer vendor? The one who has never had a technical implementation defect, nor ever cooperated with a malicious "highly capable attacker"? Fortunately, users of modern computers universally appreciate these nuances!
- Nimur (talk) 16:51, 3 May 2018 (UTC)
- SSL decription is a feature on some enterprise proxy servers. If done properly, the only noticeable difference is the SSL fingerprint, which can sometimes be buried pretty deep behind those "secure" browser icons. It can be helpful to periodically compare SSL fingerprints you receive to a known good list of fingerprints (e.g. [1]) to ensure you're getting the SSL cert from the correct source. Random character sequence (talk) 20:08, 3 May 2018 (UTC)
- None of which will accomplish anything if the hardware has a backdoor in it, or the compiler used to build your software. You only use software you've personally written, right? And what if the computer seller is just a front organization for some intelligence agency to kidnap you and haul you off to a black site? What if this is all a dream you're having? At some point you have to put some trust in other people to function in society; the alternative is to go live in the middle of nowhere, never interact with another human, and only use things you've created yourself. --47.146.63.87 (talk) 01:19, 4 May 2018 (UTC)
I wonder if many of these responses above are perhaps missing one thing. The OP said "
free proxy website to access another website
". Many of the above answers seem to be assuming a general HTTP/S or SOCKS or some similar sort of proxy which is added to your browser, OS or network device settings. In such cases, for HTTPS websites it's true that your browser will try to authenticate that the certificate is valid according to the trusted CAs and you will need to get the end user to add or have a CA on their device or rely on security flaws etc.But the OP's specific wording makes me think that perhaps they aren't thinking of that. They are thinging of websites which allow you to proxy another website. On random example (from a quick search) is www.croxyproxy.com. Using this is a completely different beast as you are only every on the proxy website. You don't need to go through any of that jazz. If you use it to access en.wiki.x.io for example, your browser will only verify the certificates for the servers croxyproxy uses (there seem to be multiple) and these will probably be correct etc. To be clear, by design and I guess this touches slightly on Nimur's point, all your browser is saying anything about is the connection between you and croxyproxy's servers. What happens between their servers and en.wiki.x.io is completely up to them, there is no need to do anything special.
This is different from the earlier scenario outline above where if I were to put a HTTP/S or SOCKS proxy the browser is still supposed to be showing info on the connection between you and en.wiki.x.io or whatever. You can seen this by looking at the address bar.
The related point which comes up in phishing attacks. While ideally you should type the URL yourself or use a bookmark or verify the info manually particularly when using financial services websites, realistically few do this and it's not even possible. At a minimum though, you should glance at the address bar and verify the domain name. The number of possible attacks is far more limited now then in the past [2], so most of the time, if the address bar says paypal.com or hsbc.com.my or whatever, you can be confident that's where you are.
If you tried this on croxyproxy, you will see something like wikiresources.download or contentserving.pw or something. So there is no need for anything complicated to do MITM. Anything between contentserving.pw or whatever and en.wiki.x.io or paypal.com or hsbc.com.my is completely unchecked by your end. I shouldn't need to say this but I guess I should just in case, this means I strongly recommend against you using croxyproxy or any other such services to access anything where you are concerned about MITM especially financial services websites. At least for TLS sites, I'd go as far as to say you're likely better off using Tor (anonymity network).
For those with a bit less technical skill, here is a simple explanation. Think of the whisper game.
- Proxy website: Instead of asking your sister, you ask your mother for an answer. Your mother asks your sister, sister answers your mother, your mother answers you. You cannot know for sure what your sister said, but you know that your mother knows what you asked your sister. Yes this is a 'type of' man in the middle, but at least you know there IS a (wo)man in the middle.
- Man (here an alien) in the middle attack (in the context of https): You ask your sister a question. Your sister answers you the question. But your sister has an alien parasite, and the parasite knows everything both of you whispered, and might have made your sister say something different from what she believes she said. Neither of you realizes something is wrong.
—TheDJ (talk • contribs) 12:06, 4 May 2018 (UTC)
- I usually go with the postal service analogy. In the proxy example, you mail your mother and ask her to ask your sister a question, and give you her reply. In the man-in-the-middle, you mail your sister a question, and she mails you her reply, but unbeknownst to both you and your sister someone intercepts your mail and reads it. By obvious corollary, said person could also keep all the mail they intercept and send both of you forged mail with whatever they want inside. --47.146.63.87 (talk) 20:34, 4 May 2018 (UTC)