Comments explaining what the code does, which is what an LLM could answer, are basically useless comments. Comments that describes why the code is how it is, is a bit more valuable, but also something LLMs cannot really reliably infer by just looking at the code.
Mathematics is the FORTRAN of the real source. Closer to a real source is probably "real" things like atoms and other universal things.
If I remember correctly, Stargate-SG1 at one point had some ideas about this sort of universal language, that multiple species could use for communication, as any sufficiently intelligent specie probably been able to see atoms and so on, but may have completely other way of doing "math-like" stuff.
The author lists all the advantes of CA certificates, yet doesn't list the disadvantages. OTOH, all the many steps required to set it up make the disadvantages rather obvious.
Also, I've never had a security issue due to TOFU, have you?
Certificates provide extra features, like revocation.
However, if you do not need the extra features provided by certificates, using SSH-generated keys is strictly equivalent with using certificates and it requires less work.
TOFU is neither necessary nor recommended, it is just a convenience feature, to be used when security may be lax.
The secure way to use SSH is to never use TOFU but to pair the user and the server by copying the public keys between the 2 computers through a secure channel, e.g. either by using a USB memory or by sending the public keys through already existing authenticated encrypted links that pass through other computers. (Such a link may be a HTTPS download link.)
When using certificates, a completely identical procedure must be used. After certificates are generated, like also after SSH keys are generated, the certificates must be copied to the client computer and the server computer through secure channels.
> secure channel, e.g. either by using a USB memory
Aside: We need a "safely dumb" storage plug standard. Right now the flexibility of USB is a double-edged sword, any USB device could potentially be malicious, waiting for the right moment to send keystrokes as a keyboard etc.
Or use the same plug for everything, but support a "passive storage only" that can be enforced by a special adapter or cable.
Just to make it clear: this does not mean that it is fine to blindly accept the message on first use.
The "secure way" implies copying the server's public key as well, which people generally don't do, right? Which is equivalent to verifying the fingerprint shown with the TOFU message, correct?
Like I have said the secure way requires the secure copying of both keys before the first connection attempt
The server public key must be copied into "known_hosts" on the client, while the client public key must be copied into "authorized_keys" on the server.
When this is the procedure that is always followed, any message shown by SSH about an unknown host means that the connection must be aborted, because the identity of the server is unknown.
You cannot truly verify the "fingerprint" displayed by SSH, unless you simultaneously have access to another computer, where you have a copy of the fingerprint. What is usually meant by "verifying" is that you remember a few digits of the fingerprint, and those match.
You could have copied the fingerprint from the server, to be able to truly verify it, but that does not make sense, because in that case you should have copied the entire key, not just the fingerprint, and you should have installed it in the client.
When you use only authentication with digital signatures, it does not make sense to use any other procedure, because you must make at least one of the two copies anyway, so when copying the client key to the server you can take the server key, to carry it back to the client.
The TOFU method is meant to be used together with password-based authentication, in less secure applications, where no physical access to the server is required for setting up SSH on the client.
By "less secure" I mean for example applications equivalent to HTTPS, where the client is not really authenticated, e.g. when providing a public password allowing read-only access to an SSH server through Internet.
Sure, I just wanted to make sure that nobody would understand "TOFU is neither necessary nor recommended, just ignore that message and say "yes" when it appears".
Both ends need to be sure of who is on the other end, and there are different ways to achieve that. The way SSH works is that if you haven't copied the server public key locally, it will explicitly ask you to verify it the first time.
I am not sure that "SSH does TOFU". SSH asks you to verify. The human who YOLOs it and approves it without checking is the one doing TOFU, and this is not really secure.
> When using certificates, a completely identical procedure must be used. After certificates are generated, like also after SSH keys are generated, the certificates must be copied to the client computer and the server computer through secure channels.
That is not the case, and is a major advantage of certificates.
What you say is extremely wrong and this misconception is very dangerous.
When an authenticated connection between a client and a server (or any other 2 computers) is established, before the connection can be initiated both ends must already have a piece of information that has been copied to them through a secure channel, otherwise the authentication is impossible.
The 2 pieces of information may allow direct reciprocal authentication, i.e. the client may have the server certificate and the server may have the client certificate.
It is also possible to have indirect authentication, e.g. the server sends the server certificate to the client and the client sends the client certificate to the server during the initiation of the connection.
However, for indirect authentication, both the client and the server must had been previously paired with a server hosting the certification authority.
This means that the root certificate of the CA must have been transferred through secure channels to the client and to the server, and also that the client certificate and the server certificate must have been transferred through secure channels to the CA for signing and then back to the client and the server.
So setting up the computers for indirect authentication through certificates requires significantly more transfers through secure channels than setting them up for direct authentication.
The advantage of indirect authentication appears in an organization with a great number of computers, where indirect authentication reduces the number of secure pairings that must be done from N*(N-1)/2 to N.
However this has nothing to do with certificates. Indirect authentication can be done without certificates, like in Kerberos, or like in SSH if you have a management computer that you pair by copying the public_keys with every computer in the network. Later, whenever you want to enable some client to connect to a SSH server you use the management computer to copy securely the corresponding public_keys between the server and the client.
So no, there is no advantage of certificates related to reducing the number of transfers that must be done through secure side channels, like copying through a portable memory.
Certificates provide other features, like temporary validity and revocation, which can be useful in an enterprise context.
What misconception? You essentially admit that I'm right in this comment but surround it with a bunch of other unrelated words.
If you use SSH certificates, then you have to put the SSH CA cert on each server once, and you have to give signed certs back to each client once each time you sign a cert (which can be once per client or once per connection or anywhere in between).
You do not have to copy anything new to each server when you sign new client certs. Likewise if you sign host keys, you don't have to copy a new host key to your client when you add a new server.
Sure, you could get the same kind of trust relationships with other tools. But SSH certificates provide them and are an advantage of SSH certificates over traditional SSH public key auth.
It honestly feels like you're just dropping this thread into an LLM and asking it to write a disagreeing response.
Not just your ISP. If an attacker slipped a device onto your LAN and also you happened to be sshing to a new box for the first time then TOFU poses a problem. But that's an awfully limited attack surface. It's similar to the difference between leaking a fax while it's sent versus leaking years old emails that are just sitting there on an internet accessible server.
As for your ISP I think you should never rely on TOFU over the public internet. If you really don't want to do ssh certs it's easy enough to make the host key available securely via https.
Choosing to use TOFU is a distinct choice from the choice of using the keys generated by SSH, instead of using certificates.
If you do not want to use TOFU, for extra security, you just have to pair the computers by copying between them the corresponding public keys through a secure channel, e.g. by using a USB memory.
Using certificates does not add any simplification or any extra security.
For real security, you still must pair the communicating computers by copying between them the corresponding certificates, through a secure channel, e.g. a USB memory.
When you use for HTTPS the certificates that have come with your Internet browser, you trust that the installer package for the browser has come to that computer through a secure channel from the authority that has created the certificates. This is usually an assumption much more far fetched than the assumption that you can trust TOFU between computers under your control.
Certificates may be useful in big organizations, if other functionality is needed beyond just establishing secure communication channels, e.g. if you want to use certificate revocation.
In the list of "advantages" enumerated in the parent article, more than half of them are false, because if certificates are implemented correctly, completely equivalent actions must be executed when SSH keys without TOFU are used and when certificates are used.
Perhaps the author meant by writing some of the "advantages" that the actions that supposedly are no longer needed with certificates are done by an administrator, not by the user. However that is also applicable with SSH. An administrator could install the certificates, so that no action is required from the user, but an administrator can also install the SSH public keys, so that no TOFU is ever needed from the user.
Using certificates requires exactly the same steps like using keys generated by SSH (i.e. generating certificates and copying them between computers through secure channels, to pair the servers and the authorized users), but it may need additional steps, caused by the fact that certificates provide additional functionality.
Touche.. actually a good point, but actually those are two different situations.
With one, I'm accessing a website and trusting that the certificate is signed by someone I trust; so the trust in my browser certificates (which include certificates from hundreds of certificate authorities all over the world, any one of which could be compromised, robbed, or controlled by an adversarial person or even government) is extended to the site that I'm visiting. To say this is weak sauce rather understates how bad this actually is. (To paraphrase Churchill, this is the worst possible design, except for all the rest.)
With the other, I'm logging into a server for the first time (and I could simply deploy the same trusted host key to all my ssh servers via an autoscaling configuration or whatever). I think it's debatable if TOFU is worse or better than your (granted clever) metaphor.
(to those who'd recommend userify, yes - great for the client login issue and definitely increases security, but to parent's point, TOFU is still needed unless you want to distribute host pubkeys)
Pairing is absolutely necessary for bidirectional authentication, where each party must verify the identity of the other end.
To visit this site, there is no pairing, because the site does not know who I am.
In order to verify the identity of the HN site, I must trust that the maintainers of the installation packages of the browsers that I use (Firefox, Vivaldi, Chromium) have ensured that the built-in certificates have reached me through a secure path. This actually requires much more trust than when someone answers "yes" to the SSH unknown host message.
If I use certificates for accessing e.g. the network of my employer, then my work computer must be paired with some corporate server, i.e. a unique certificate has been generated for myself and it has been copied to some certificate authority server for signing and then to my computer, and also a certificate of the local certificate authority has been copied to my personal computer.
While pairing is unavoidable for bidirectional authentication, it is not necessarily direct between the end points. Both end points must have been paired with at least one other computer but they need not have been paired between themselves previously if there exists some path through secure connections that have been originally created by pairing.
When certificates are used, usually the pairings are not done directly between end points, but each computer must be paired with the server hosting the certificate authority.
The term "pairing" is not used frequently, but it should have been preferred, because frequently the users do not understand which are the exact actions on which the security of their communications depend, which leads to various exploits. The critical security actions are those that perform the pairing.
"Pairing" of 2 systems, e.g. A and B, means that some information must be transmitted through a secure channel from A to B and some other information must be transmitted through a secure channel from B to A. An alternative pairing method is to generate both pieces of information on one of the 2 systems and transmit both of them through a secure channel to the other. The information exchange channels must already be secure, because before pairing authentication is impossible.
The pairing between a PC and the server hosting the certificate authority can be done in various ways, depending on where the PC certificate is generated. If the certificate is generated at the certificate authority than both it and the root certificate must be copied through a secure channel to the PC. If the certificate is generated on the PC, it must be sent through a secure channel to the CA for signing, then it must be sent back also through a secure channel.
In practice, administrators are not always careful enough for the channels through which certificates are copied to be really secure. For instance they may be copied through network links that are not yet authenticated, which is equivalent with the TOFU method optionally used by SSH.
If you have some form of access to set up the CA config on the box before connecting then you can use the same access channel to avoid needing to rely on TOFU for setting up the key access all the same.
This can be anything from being part of the install script to customized deployment image to physical access to access via a host in virtualized scenarios.
TOFU only really comes into play when the box is already set up and you have no other way to load things onto the box other than connecting via SSH to do so. But, again, that would be the same story if you were intending to go the certificate approach too.
Well the car has done 50,000km before I bought it and tbh in the winter it lost quite a bit of range (I've had a different EV previously and its range didn't decrease as much during the winter).
The car has a warranty on the battery valid for 8 years or 160,000km (whatever occurs first), the manufacturer promises it will have 70% or more capacity at that point.
ADAC did a test with a vehicle that reached 160,000km and its battery was at 91%.
I roll my eyes at this question because it's often framed as good faith curiosity, but it's often asked in bad faith by people that think it's a "gotcha" question, because they have this incorrect notion that EV batteries need to be replaced frequently. They see the warranty is 100K miles/8 years or whatever and think that means they have to replace the battery after 100K miles/8 years, yet fail to recognize that they don't apply that same logic to combustion engines with 30K mile/3 year warranties.
> As of 2025, the average age of a scrapped car in the UK is between 16 and 20 years old!
...
> You can also buy used EVs.
True, but you're quite limited there since good EVs have only been around for a very small number of years. Maybe you can get an old Tesla for not too much but that's pretty undesirable for obvious reasons.
> True, but you're quite limited there since good EVs have only been around for a very small number of years
You'd think that, but (I am shopping at the moment) it is routine to see last year's EVs on Autotrader, at 30-50% off list price. That does make me a little suspicious (is this being got rid of because it's a lemon?), but they're there.
I think we can narrow the statement to "if you are buying a new or nearly-new car, or leasing, and you can charge at home or work, you should seriously consider an EV". Fleet and business use should definitely be thinking very hard about it.
There is a huge difference between these two statements:
> most people keep cars for 20 years or more
and
> the average age of a scrapped car in the UK is between 16 and 20 years old
Because the second fact doesn't tell you whether or not the 1st fact is true.
After all, there is a second hand market where you can find cars of every age.
If most people kept cars for 20 years, and the secondhand market exists, then by the time an average car is scrapped it must be substantially over 20 years old.
Yes. Like they did with the githubsearch for users that are not logged in.
At first, they brought it back. Then they changed to limits so you get between zero and two searches before getting an error message that you have hit some kind of limit.
If you're purely repurposing hardware that you need anyway for other uses, that doesn't really matter.
(Besides, for that matter, your utilization might actually rise if you're making do with potato-class hardware that can only achieve low throughput and high latency. You'd be running inference in the background, basically at all times.)
reply