When I think "the fundamental problem", the closest thing that comes to my mind is "unsolvable problem". P =/!= NP is a fundamental problem, the theory of everything is a fundamental problem.

But we actually solved at least one such problem – the fundamental problem of cryptography.

The problem was "how to establish a secure connection over a non-secure channel?" Like you can't exchange the key, it'll be exposed by definition.

We solved it with a simple yet brilliant solution of asymmetrical cypher, that thing with public and private keys.

It's fascinating to think that people died in WW2 over this, there were special operations to deliver fresh deciphering keys securely and now SSH and HTTPS are no-brainers that literally everyone use.

@uyouthe I assume you know that if a middle man can read your data he is also capable of changing it, So, Even while using asymmetric Encryption over a network, While exchanging public keys, He may change it with the one he has. And, Since you tagged me here, I assume you are referring from that Apple discussion. This is not even remotely related to that.

@theabbie I tagged you because you inspired me to post this rant.

Also please refrain of posting anything related to cybersec please, at least for now, I'm begging you
https://security.stackexchange.com/...

@uyouthe Well, Your link does say that he can replace the certificate, Yeah, That would destroy the signature, But, It can be done. It will create warning which most people ignore. And, I had never criticized this method. It's good.

@theabbie here's the public SSH key of my highest privileged environment that has access to all of my servers, enjoy! :)

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHcJeqGLlVwzXpm0Cdk4fWdD0GWoFaHifNBcAlgzT+9G condor@cmd

Asymmetric cryptography is quite a beautiful thing really, you can share your public keys pretty much anywhere without ever exposing any private key material. With public keys you can also encrypt data to the owner of the private equivalent. With your own private key you can sign data to confirm that it's you who sent it. It's amazing!

That said SSH is definitely not perfect, and it's shown by TOFU being the most popular authentication method by far (rather than the also existing but barely known SSH CA) and SSH key agents residing in /tmp with its 777 mode. Storing those things in /tmp is a terrible idea. There are other things as well but those are some. But the asymmetric cryptography itself? It's being put through its paces all the time by cryptanalysts.

@theabbie Unsigned certs are impossible to use within any browser if the website has ever sent HSTS headers, which all big sites have. Even if it hasn't, it has been added to a HSTS list and will not accept invalid or unsigned certs.
MITM is dead with HTTPS, unless you're a three letter agency with access to a root certificate of a trusted CA.
And no, you literally cannot ignore invalid certificate warnings.

@Condor while posting this chat message if the man in the middle modified your message and put his public key instead of yours, that's a threat. And regarding HTTPS, If you use Public WIFI set up by an attacker, HTTPS won't help either.

@theabbie With HTTPS the public keys of the websites - along with the domain - are transferred in a certificate that's signed by a trusted CA. Public keys of the trusted CAs are distributed with the browser, and as such, never transferred over the untrusted connection. If the browser finds that the cert isn't properly signed, it won't just show an error, it'll paint the screen yellow and yell at the user that the website had definitely been tampered with.

@theabbie my web browser checks devRant's certificate every time. If it doesn't match and the website doesn't use HSTS (devRant doesn't and shouldn't because HSTS doesn't scale up properly), my browser will show a warning. I can choose to go back or proceed on the insecure site (proceeding might be viable on public resources). The reason for it might be as simple as an expired certificate. If you check the certificate on e.g. my Gitea instance (https://git.ghnou.su) you'll find that Let's Encrypt requires renewal every 3 months. Sometimes people just forget to do it. If the site does have HSTS however, visit it once and you can't MITM it anymore at all. But again, doesn't scale up. Don't waste the HSTS list's resources for a shitty blog or something.

As far as MITM goes on my particular network.. you'll need to have a black box after my network edges that I VPN into. If you're a government entity then maybe you do have one planted. But somehow I doubt that.

If you want an example of poorly implemented TLS, don't look at web browsers - they've pretty much got it figured out at this point. Look at mail servers instead. Sure TLS is supported there, I guess.. but everyone just uses self-signed certificates and the SMTP protocol will actively downgrade a connection to plain if there's anything wrong with it. That's exactly what an MITM attacker wants. And you've got pretty much everyone supporting TLS on their mail servers, except.. oh wait.. yeah government, shit you don't have TLS implemented at all? You fucking motherf-...

Anyway opportunistic TLS is necessary for those cases - you can't enforce it on your own mail server if you want to send to servers not supporting it. With that said, the chance of any skid being able to put themselves in a route between datacenters where mail servers reside is pretty slim. Half the time all they got is a phone running Termux... :')