Is it possible to sniff SSL without a MITM attack? I'm worried

Stop watching cp

>>60864864
No, it's not.

You should work on understanding how the computers you use work, dude.
But first I'd recommend learning what a MITM actually is. It stands for fucking google it you dumb asshole.

Protip: your ISP is literally the man in the middle.

Secondly learn how encryption works, notably SSL, and DH.

>>60864927
lel
I'm actually worried about political persecution. The ISP is a public company in my country.
>>60864965
>But first I'd recommend learning what a MITM actually is. It stands for fucking google it you dumb asshole.
>Protip: your ISP is literally the man in the middle.
I understand this, but by "MITM attack" I was talking about the specific kind of attack where there's a spoofed website/server/whatever that shows the client a duplicate.
>Secondly learn how encryption works, notably SSL, and DH.
I tried but I seem to lack prerequisite knowledge. Where could I find good resources about this? How do I git gud on security?
For the record I'm not a CS student or whatever. I specifically avoided that career because I wanted to be able to enjoy computers and not turn them into my job.

>>60864864
It is not possible without knowing the private key which is never transmitted.

>>60865021
>someone capturing the "handshake" and using it to decrypt communications
First of all, look public/private key authentication. There's a wikipedia page. Look for alice & bob diagrams showing how one key encrypts and the other decrypts and such. Now, understanding that, the tl;dr version of why what I quoted won't happen is that only public keys go over the wire unencrypted. During the handshake, a shared key is agreed upon without ever actually sending that key over the wire; thus, anyone in the middle won't know what the key is and will be in the dark once both sides switch to encrypted communication. The specifics are much more complicated, as is the way with crypto: https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work

>where there's a spoofed website/server/whatever that shows the client a duplicate
Now this is different. Someone is in the middle and acting as a proxy, but since their cert doesn't match the domain, you get that ssl warning. If you bypass that, you have agreed that you're ok talking to this server, without knowing who they are. So of course they can see your traffic -- they're the one you decided to talk to! Hence why you should be very skeptical whenever you see an ssl warning, and if you bypass it, assume that anyone could be listening.

>>60865239
>During the handshake, a shared key is agreed upon without ever actually sending that key over the wire; thus, anyone in the middle won't know what the key is and will be in the dark once both sides switch to encrypted communication.
Aren't the private keys encrypted using the public ones though?
>Now this is different. Someone is in the middle and acting as a proxy, but since their cert doesn't match the domain, you get that ssl warning.
You can get another certificate though, it's been done.

I'll read that stackexchange article now.

Not other anons but would suggest you read about forward secrecy, HMAC and how certificate signing works. If you want some fun MITM tinkering install squid and setup SSL bumping, then appreciate that green lock in your browser bar is not the same as a grey or red lock.

>>60865255
I feel like a fool now, turns out the public key is all you need to check the signature that was generated by the private key.
>>60865263
You mean it the browser will keep saying it's secure?
BTW, fun or maybe tragic thing: it's not uncommon for public sites in my country to have the wrong certs because of using subdomains. Even happened to the public bank and my university which is public too. I'm surprised people trust the bank's website. Both have long been fixed though.

>>60865306
>You mean the browser will keep saying it's secure?
Fixed
sorry for the incoherent original sentence