>If I can MITM your http connection, I can MITM your https connection. No you can't, that's the whole point of public key encryption. Someone could give you ev

>If I can MITM your http connection, I can MITM your https connection. No you can't, that's the whole point of public key encryption. Someone could give you every single byte, in order, from the entire two way negoatiation process, and you would still not be able to to MITM your way into the datastream unless you either reverse engineered both party's secret keys that are used to perform the {sender locks lock, send locked data, receiver counter locks, sends doubly locked data back, sender unlocks, send counter-locked-only data, receiver counter unlocks, receiver now has the original data} step. Unless you know BOTH keys that were used in the purely local locks, you can do exactly nothing at all despite seeing every single naked byte involved. Can you MITM it if you already know the keys? Of course. But that is not an argument against HTTPS, of course. Can you guess or compute the keys if you don't have them? Given enough time, again: of course. Can known shortcomings in a known cypher make the job of computing keys easier? third time: of course. And that's why HTTPS lets you specify which "secure, today" cyphers to use, and which "no longer, or never secure" cyphers you will absolutely not accept. HTTPS with sha-1 was very secure years ago, for instance. Today it's a stupid choice if you want to remain secure, because its too easy to break. HTTPS makes MITM "the least possible" by using a secure symmetric encryption for both parties to agree on which asymmetric encryption to use. And it lets parties agree on stronger and stronger cyphers as time goes on, so that the integrity of connections stays a moving target. MITM is a theoretical possibility, but unless you literally own a half-a-billion dollar supercomputer capable of factoring large primes in a reasonable amount of time, can you, personally? Plain and simple no.