please lets not confuse the issue with PDF -- I know PDF internals actually, and do infact d-compile and rebuild PDF is I think there is anything fishy.. zero point zero Javascript and PDF in this setup
I understand you know PDF internals and you can verify that you're not serving javascript in your PDF content. I'm glad you've gone to that depth of knowledge!
But I'm saying that what you're serving and what the user receives can be different. When you're using plain unencrypted HTTP then anyone between you and the user can inject javascript into the PDF. The user can get a PDF file with javascript in it even though you didn't put any javascript in it.
And while I think that most people reading HN would understand this, it doesn't have to be an ISP, just somebody that controls a network device between you and the destination. eg, a public wifi hotspot.
That's pretty much all it ends up stopping. Some hacker-wannabe that sets up a honey pot is going to be thwarted by HTTPS. But if we don't connect to shady hot spots HTTPS doesn't seem to provide that much protection. It runs into the problem of anyone that can MITM via your ISP or home router probably has the resources to also find an exploit around HTTPS.
> Some hacker-wannabe that sets up a honey pot is going to be thwarted by HTTPS. But if we don't connect to shady hot spots HTTPS doesn't seem to provide that much protection.
Pinned HTTPS certificates provide a good degree of resistance to MITM attacks, and without installing local certificates on the device under attack HTTPS itself stops MITM attacks.
> It runs into the problem of anyone that can MITM via your ISP or home router probably has the resources to also find an exploit around HTTPS.
This is absolutely not the case. Home/work routers are often monitored by suspicious spouses, annoying housemates or intrusive companies. It's very rare that one of these has the resources to develop their own exploits against HTTPS.
>This is absolutely not the case. Home/work routers are often monitored by suspicious spouses, annoying housemates or intrusive companies. It's very rare that one of these has the resources to develop their own exploits against HTTPS
I didn't say against, I said around. And your hypotheticals are good examples of that. If we are giving our bad actor physical access to devices in the house there are a lot easier/more effective attacks than a MITM on the router. Keyloggers, spy software, webcams, etc. are simpler and more effective tools. If they're sophisticated enough to do a believable MITM attack they can do all these other attacks as well.
> Keyloggers, spy software, webcams, etc. are simpler and more effective tools. If they're sophisticated enough to do a believable MITM attack they can do all these other attacks as well.
This isn't true. All of these attacks are pretty hard to run against mobile devices unless you can install something on them.
> a believable MITM attack
This makes me think you don't actually know what a MITM attack is. MITM attacks are dangerous because they are invisible - ie, "believable" is implied by it being a MITM attack.
