3 ms·

The key difference is https certificates often require signing authority integrity, and leak-free SSL libraries. Traditionally both facets of the 3rd party tru

The key difference is https certificates often require signing authority integrity, and leak-free SSL libraries. Traditionally both facets of the 3rd party trust model have had CVE over the years. SSL protocol misconfiguration is also very common, and connections can be downgraded by adversaries into a vulnerable version of the protocol. It could be argued ssh is a weaker Trust on first use model, but in most cases the keys will rarely change for the short service life of the server instance... and the server may be setup from a local physical terminal, and keys communicated out-of-band to remote users. At some point one has to admit if someone really wants in they will physically pull the drive in the data center. However, people using web vulnerability scanners on your systems are less of a nuisance. Best regards =3

fc417fc802 2y ago
> It could be argued ssh is a weaker Trust on first use model That is but an optional aspect of the configuration (albeit by far the most common).
crote 2y ago
> The key difference is https certificates often require signing authority integrity Couldn't you use your "traditional" SSH keys to generate an ephemeral self-signed client certificate which shares the same keypair as your SSH key? That would at least solve the CA issue for the client-to-server authentication.
- Joel_Mckay 2y ago
  It is a complex issue, and while public key encrypted exchanges could bootstrap a remote secure session (gpg/pgp etc.) to re-key the ssh server... there still is no guarantee someone isn't keeping a copy of that ssh session with the key-pair before you logged in as root. One should not completely trust TOFU over remote sessions, but it is the most practical solution. This is the inconvenient secret of cloud technology, and why the hosting company web panels often include abstracted firewall/vpn settings or proprietary key management (or the same authoritative problem manifests.) Good luck, =3

fc417fc802 2y ago

> It could be argued ssh is a weaker Trust on first use model That is but an optional aspect of the configuration (albeit by far the most common).

crote 2y ago

> The key difference is https certificates often require signing authority integrity Couldn't you use your "traditional" SSH keys to generate an ephemeral self-signed client certificate which shares the same keypair as your SSH key? That would at least solve the CA issue for the client-to-server authentication.

Joel_Mckay 2y ago
It is a complex issue, and while public key encrypted exchanges could bootstrap a remote secure session (gpg/pgp etc.) to re-key the ssh server... there still is no guarantee someone isn't keeping a copy of that ssh session with the key-pair before you logged in as root. One should not completely trust TOFU over remote sessions, but it is the most practical solution. This is the inconvenient secret of cloud technology, and why the hosting company web panels often include abstracted firewall/vpn settings or proprietary key management (or the same authoritative problem manifests.) Good luck, =3