> Doing terrible work every 2 years is better than doing it every day?
And by skipping some releases, you will have less of that work. When something is changed in one release, then changed again on the next one, by waiting you only have to do the change once, instead of twice. And sometimes you don't even have to do anything, when something is introduced in one release and reverted in the next one.
> It's important to look at the actual vulnerability at the context, and not just list any CVE which matches by version.
Unfortunately, that's not enough. Even if the vulnerable parts of the code are not being built, heck even if they have been completely erased from the source code, the auditors will still insist that you're vulnerable and must immediately upgrade, or else they will give your software a failing grade.
> Other comments say that this mitm stops working when you use public key authentication.
It doesn't completely stop working; a MITM can still pretend to be the server, it just can't authenticate to the real server on your behalf. You could be doing all your work in a fake server controlled by the attacker, while the real server sits there untouched.
It does note that it only protects against an attacker "who learns the cloud-init user-data at any point after the script terminates".
If the attacker can get the cloud-init user-data while the script is still running (in the time between sending the cloud-config.yaml and connecting with SSH to the machine) that would still allow MitM, but would require more effort on the attacker's part to leak the cloud-init data.
The point of the script was that leaking the cloud-init data after the script has completed is harmless.
Yes, I'm just saying if you think you've set up a server with Hetzner, but Smersh is able to intercept your first interaction with it and present you a server that you think is the one you created, then it doesn't matter how much you try to harden the compromised server. But if you get MITM later in the the process, the above is the scenario you are worried about.
> Couldn’t the MITM ssh server just forward the client’s fingerprint to the legitimate server?
The client sends not only the public key, but also a signature, and that signature depends on the output from the key exchange, so it's "bound" to the shared keys negotiated between the client and the server. If the MITM server does separate key exchanges with the client (pretending to be the real server) and the server (pretending to be the real client), the signature won't match; if it forwards the key exchange between the real client and the real server, it won't be able to decrypt the packets.
That's the best thing about SSH public key authentication (and HTTPS client certificates): even when MITM can impersonate the server to the client (because the client didn't verify the host key), it can't impersonate the client to the real server.
Let me see if I understand correctly: Client takes its own public key and the server's public key and creates this signature.
MITM can take its public key and the client's public key and send the resulting signature to the server instead of forwarding what it received from the client.
Do pretty much the same exact thing: MITM PK + Server's PK -> Client. Now client has a signature as well. The signatures that client and server have are different but that is OK as long as MITM can see and change all communication.
It has been a while since I went through the details of the protocol, so I must be missing something. What is it?
> MITM can take its public key and the client's public key and send the resulting signature to the server instead of forwarding what it received from the client.
That's not possible, since the MITM doesn't know the client's private key (and using a different public key will be rejected by the server).
> Do pretty much the same exact thing: MITM PK + Server's PK -> Client. Now client has a signature as well. The signatures that client and server have are different but that is OK as long as MITM can see and change all communication.
You're confusing the Diffie-Hellman Key Exchange with the Public Key Authentication Method. When you MITM the key exchange, the shared secrets the client and server have are different (one side has a secret derived from the client and MITM keys, the other side has a secret derived from the MITM and server keys), but that works as long as the MITM can see and change all communication (basically, decrypting it and encrypting it again).
But since the secrets are different, the session identifier is also different. The MITM can't forward the signature from the client since the server will fail to verify it due to the mismatch in the session identifier; the MiTM can't create a new signature with the client public key since it doesn't have the corresponding private key; and the MITM can't create a valid signature with its own public key (and the corresponding private key) since that key won't be in the authorized keys list for that user account in the server.
The reason Pix needs a Brazilian bank account, is that at its core, it's just a bank transfer mechanism, like the older TED or DOC. Pix sends money from one bank account to another bank account. The main novelties are being instant, working 24h per day, and being able to use keys like a phone number or email as destinations (the Brazilian Central Bank has a central database which maps these keys to the bank account numbers).
> in some countries banks have been removing functionality from their online-banking website, and you can only do certain things in the phone app.
The most infuriating I've seen, is a bank which removed the anual tax report (which you need to do the anual income tax) from the online-banking website, requiring you to use the phone app... to download a PDF file, which you then have to transfer to the computer anyway so you can print it!
Can I buy a Librem 5 here in Brazil? (Unless it has ANATEL certification, which I doubt it has, buying online from outside the country is not an option, since it will be rejected by customs.)
> As long as developers can opt into the new system (which they can with the manifest approach) [...] Microsoft has added a mishmash of flags in the app manifest
I don't see why you'd need a separate flag for memory management, Windows version, printer driver isolation, awareness of long paths, and all of that jazz.
And by skipping some releases, you will have less of that work. When something is changed in one release, then changed again on the next one, by waiting you only have to do the change once, instead of twice. And sometimes you don't even have to do anything, when something is introduced in one release and reverted in the next one.
reply