291–300 of 311 posts
Earlier quoted context omitted.
I feel Firesheep deserves at least some of the credit too: https://en.wikipedia.org/wiki/Firesheep
Firesheep co-author here. Thanks and agreed :)
got there from official blog https://codebutler.com/2010/10/24/firesheep/
Maybe force https when requesting http ?
https://drive.google.com/file/d/1maSpqYfFoBoCyao14VKzLKPMlm9...
What if you're prone to release huge turds that often clog the toilets?
Earlier quoted context omitted.
MITM is not mitigated at all by HTTPS. What makes you think that? Do you understand how certificate signing works?
How does certificate signing not mitigate man-in-the-middle? Say you have control of DNS and you can fully impersonate and replace any server. You present a valid certificate for the server. It has the public key, which the client uses to try to encrypt traffic. The man-in-the-middle doesn't have the private certificate. You convince the client its talking to the right machine, but then you can't understand anything…
Certificate Transparency exists, solely because any CA can issue an SSL cert for any domain, and use it to MITM via a proxy.
You are trusting every CA out there, not just Verisign. That is the ultimate weakness. Any CA can issue a cert for any domain.
Expect-CT header is the only thing protecting you from a MITM, and it's not even a protection, really, and it's trivial to strip that header as the MITM before proxying to the client.
How do you think mitmproxy[0] works?
Earlier quoted context omitted.
MITM is not mitigated at all by HTTPS. What makes you think that? Do you understand how certificate signing works?
...do you? Unless the attacker has access to the private key associated with the SSL certificate, they can't read any HTTPS traffic encrypted via that certificate - mitigating the ability of that bad actor to perform a MITM attack.
Two things...
Proxies are a thing, and stripping the Expect-CT header is trivial.
Any CA can generate a valid SSL cert for any domain.
Earlier quoted context omitted.
...do you? Unless the attacker has access to the private key associated with the SSL certificate, they can't read any HTTPS traffic encrypted via that certificate - mitigating the ability of that bad actor to perform a MITM attack.
And even if they get a key, they will show up in the CT Logs eventually and the attack becomes public.
Earlier quoted context omitted.
MITM is not mitigated at all by HTTPS. What makes you think that? Do you understand how certificate signing works?
If https doe not mitigate MITM attacks, what is the purpose of it?
Earlier quoted context omitted.
TIL that content for wikipedia pages changes per language. I clicked 'English' in the left pane hoping to learn more about what you are saying, but the English version does not have the 'En Europe' section. not so great. Thanks for your post
Different wikipedia language pages have completely different people working on them with completely different biases and politics behind them.
This seems pretty reasonable seen for the whole encyclopedia, but I suppose if you assume that the language change option will just translate the page you're currently looking at then it's quite a surprise.
Earlier quoted context omitted.
Snowden released a large collection of documents. Judging by his interview with Joe Rogan, he's a passionate advocate for encryption and says that the US is creating a tool for complete oppression. It's harder to get more apocalyptic than that.
If you want to win against a view, select a leader from your pocket, make him look plausible and make him take control of the whole view. At any point you desire, let that person discredit himself and take the whole view down.
Earlier quoted context omitted.
> Nice. Remember the days when IT professionals would exclaim that this was a bad idea? It has made some things more difficult. In the old days when I had problems with a remote IMAP server I could watch each command and response going over the wire. It made troubleshooting dead simple. When a POP3 mailbox got hung up on a single huge message you could just telnet in and delete the offending message in a few seconds.…
> I could watch each command and response going over the wire. AFAIK, Wireshark supports decrypting TLS traffic if you give it the private keys. > When a POP3 mailbox got hung up on a single huge message you could just telnet in Use “gnutls-cli” or “openssl s_client” – transparent TLS for your terminal. Both those commands also have options supporting protocols’ use of STARTTLS.
Private keys in modern TLS are used only to prove who you are, they aren't used to decrypt anything. Instead random ephemeral secrets are chosen by both sides and a Diffie-Hellman (ECDH) key agreement method is used to agree a shared secret based on those ephemeral secrets.
As a result of this design the connection is encrypted and delivers integrity and confidentiality protection before either side knows who they're talking to.