3 ms·

1. You 're the one that told me I had control of the client network as per MITM; don't move the goalposts. 2. You're overthinking this. I'm not talking about h

1. You 're the one that told me I had control of the client network as per MITM; don't move the goalposts. 2. You're overthinking this. I'm not talking about hijacking established sessions. I'm talking about never letting the authentic session start in the first place. As soon as the attacker controls the DNS resolver it doesn't matter what security you have in place. The bank and the LE servers and all that can be perfectly secure. But if the client is going to the wrong IPs they never will interact with them. They'll only interact with the perfectly valid HTTPS hosts the attacker sets up.

yjftsjthsd-h 6y ago
My initial statement was that HTTPS would prevent a third party from adding malware to a site (implicitly, "as it was loaded"), to which pbalau responded "No it doesn't." Are you suggesting that our attacker can "just" compromise the victim's machine or the hosting server? Because that's true, but HTTPS is effective against network attacks. Deploying HTTPS also won't prevent someone from mugging you IRL, but that doesn't mean that it's not an effective security measure for what it does. If we're talking about SSL Stripping, then 1. we're back to you needing to control the network, so apparently my goalposts are exactly in the right place, 2. that is at best partially effective (AFAIK, requires the victim to start from a non-HTTPS page, so again, we really want 100% of sites on HTTPS), and 3. that works specifically by getting the victim back onto insecure HTTP, so if you need that then it's proof of the effectiveness of HTTPS.
- superkuh 6y ago
  You're missing your very own point again. You guys are up in arms about potential attacks against the client or the network. Attacks that having nothing to do with the web server. I am giving examples of how that class of attacks is not mitigated by HTTPS. I am not talking about SSL stripping. I am talking about not even letting the client talk to the remote host because in the scenario where you MITM you have control of the network.
  - kawabungah 6y ago
    Assuming you own the DNS server and redirect traffic to a different IP address, how will your fake host provide the CA-verified certificate to the client?
    - superkuh 6y ago
      I thought about this a lot. You're right. There's no way. I was wrong. Sorry.

yjftsjthsd-h 6y ago

My initial statement was that HTTPS would prevent a third party from adding malware to a site (implicitly, "as it was loaded"), to which pbalau responded "No it doesn't." Are you suggesting that our attacker can "just" compromise the victim's machine or the hosting server? Because that's true, but HTTPS is effective against network attacks. Deploying HTTPS also won't prevent someone from mugging you IRL, but that doesn't mean that it's not an effective security measure for what it does. If we're talking about SSL Stripping, then 1. we're back to you needing to control the network, so apparently my goalposts are exactly in the right place, 2. that is at best partially effective (AFAIK, requires the victim to start from a non-HTTPS page, so again, we really want 100% of sites on HTTPS), and 3. that works specifically by getting the victim back onto insecure HTTP, so if you need that then it's proof of the effectiveness of HTTPS.

superkuh 6y ago
You're missing your very own point again. You guys are up in arms about potential attacks against the client or the network. Attacks that having nothing to do with the web server. I am giving examples of how that class of attacks is not mitigated by HTTPS. I am not talking about SSL stripping. I am talking about not even letting the client talk to the remote host because in the scenario where you MITM you have control of the network.
- kawabungah 6y ago
  Assuming you own the DNS server and redirect traffic to a different IP address, how will your fake host provide the CA-verified certificate to the client?
  - superkuh 6y ago
    I thought about this a lot. You're right. There's no way. I was wrong. Sorry.