Is SSH secure against MiTM if server fingerprint is not checked, public key authentication is used and confidentiality is not needed for that service?How can I authenticate a client connection in a secure way?How does ssh public key authentication work?Should the Keygen element be used to create a certificate for mutual auth TLS? What alternatives are there?Use SSH config file with PuttySSH MITM attack underwaySSH Server AuthenticationWould a hard-coded public key or fingerprint protect against MITM?Verifying SSH fingerprint of a public serverIs it possible to MITM TLS without maintaining connection between proxy and remote server?How does SSH client ensure that SSH server bears the private key, which is the pair of the public key in client's “known_hosts” file?
Everytime I convert PDF to PNG it becomes more pixely. How can I fix it?
How to fix "webpack Dev Server Invalid Options" in Vuejs
In How Many Ways Can We Partition a Set Into Smaller Subsets So The Sum of the Numbers In Each Subset Is Equal?
Gambler's Fallacy Dice
Is being an extrovert a necessary condition to be a manager?
Parse a C++14 integer literal
How do you cope with rejection?
What does this 'x' mean on the stem of the voice's note, above the notehead?
Precedent for disabled Kings
Germany rejected my entry to Schengen countries
Can't think of a good word or term to describe not feeling or thinking
Is my company merging branches wrong?
Are there any crystals that are theoretically possible, but haven't yet been made?
Would it be possible to set up a franchise in the ancient world?
Can I have a delimited macro with a literal # in the parameter text?
What does it mean for a program to be 32 or 64 bit?
Why is python script running in background consuming 100 % CPU?
DISTINCT NULL return single NULL in SQL Server
Is it possible to view all the attribute data in QGIS
How can I prevent Bash expansion from passing files starting with "-" as argument?
What is the backup for a glass cockpit, if a plane loses power to the displays/controls?
Richard's Favourite TV Programme
Hotel booking: Why is Agoda much cheaper than booking.com?
Addressing an email
Is SSH secure against MiTM if server fingerprint is not checked, public key authentication is used and confidentiality is not needed for that service?
How can I authenticate a client connection in a secure way?How does ssh public key authentication work?Should the Keygen element be used to create a certificate for mutual auth TLS? What alternatives are there?Use SSH config file with PuttySSH MITM attack underwaySSH Server AuthenticationWould a hard-coded public key or fingerprint protect against MITM?Verifying SSH fingerprint of a public serverIs it possible to MITM TLS without maintaining connection between proxy and remote server?How does SSH client ensure that SSH server bears the private key, which is the pair of the public key in client's “known_hosts” file?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
When connecting to a server for the first time, ssh usually requires users to check server's fingerprint and then caches the info. This is needed in order to prevent MiTM.
Is it a design flaw in SSH that a user is required to check fingerprint manually? I mean the following use-case.
There is a server. There is a client. The server provide some personalized services to authenticated users. So it is the server's responsibility to check user's credentials properly.
Server knows its fingerprint. Let's assume that the client (not ssh one, but an app built upon ssh, like a GUI client for git) is unwiling to check the fingerprint because in order to do it it should get the true fingerprint somehow, which means GUI for that has to be implemented.
The authentication protocol is that the client signs the challenge provided by the server, the server verifies it and then allows access. It feels like a design flaw: a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
The way to fix that would be to sign not only challenge, but also server's fingerprint. (See the accepted answer for the right picture) Then the server can detect MiTM server-side. Though it doesn't protect from a malicious server being impersonated to a user.
authentication man-in-the-middle ssh
asked May 13 at 9:02
KOLANICHKOLANICH
461413
|
show 1 more comment
When connecting to a server for the first time, ssh usually requires users to check server's fingerprint and then caches the info. This is needed in order to prevent MiTM.
Is it a design flaw in SSH that a user is required to check fingerprint manually? I mean the following use-case.
There is a server. There is a client. The server provide some personalized services to authenticated users. So it is the server's responsibility to check user's credentials properly.
Server knows its fingerprint. Let's assume that the client (not ssh one, but an app built upon ssh, like a GUI client for git) is unwiling to check the fingerprint because in order to do it it should get the true fingerprint somehow, which means GUI for that has to be implemented.
The authentication protocol is that the client signs the challenge provided by the server, the server verifies it and then allows access. It feels like a design flaw: a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
The way to fix that would be to sign not only challenge, but also server's fingerprint. (See the accepted answer for the right picture) Then the server can detect MiTM server-side. Though it doesn't protect from a malicious server being impersonated to a user.
authentication man-in-the-middle ssh
asked May 13 at 9:02
KOLANICHKOLANICH
461413
2
This mechanism is called "Trust on First Use" (TOFU).
– Sjoerd
May 13 at 9:09
Not quite what you asked, but read up on SSH CA as it addresses this problem
– paj28
May 13 at 9:24
1
@SteffenUllrich KOLANICH does propose a new scheme and is basically asking why we're all so stupid to use the current, "broken" tofu/manual-check scheme instead of what he cooked up. Not exactly a duplicate of how to find the hostkey in a trusted manner.
– Luc
May 13 at 10:12
1
@Luc: Oh, I've focused too much on 90% of the question and the title and did not see that the last two sentences had some proposal for change hidden which I did not expected from reading the title and the rest of the body.
– Steffen Ullrich
May 13 at 11:03
1
@SteffenUllrich Agreed, it's a little hidden. I initially missed it and had to edit my answer later. Might be good to edit the question.
– Luc
May 13 at 11:08
|
show 1 more comment
When connecting to a server for the first time, ssh usually requires users to check server's fingerprint and then caches the info. This is needed in order to prevent MiTM.
Is it a design flaw in SSH that a user is required to check fingerprint manually? I mean the following use-case.
There is a server. There is a client. The server provide some personalized services to authenticated users. So it is the server's responsibility to check user's credentials properly.
Server knows its fingerprint. Let's assume that the client (not ssh one, but an app built upon ssh, like a GUI client for git) is unwiling to check the fingerprint because in order to do it it should get the true fingerprint somehow, which means GUI for that has to be implemented.
The authentication protocol is that the client signs the challenge provided by the server, the server verifies it and then allows access. It feels like a design flaw: a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
The way to fix that would be to sign not only challenge, but also server's fingerprint. (See the accepted answer for the right picture) Then the server can detect MiTM server-side. Though it doesn't protect from a malicious server being impersonated to a user.
authentication man-in-the-middle ssh
asked May 13 at 9:02
KOLANICHKOLANICH
461413
When connecting to a server for the first time, ssh usually requires users to check server's fingerprint and then caches the info. This is needed in order to prevent MiTM.
Is it a design flaw in SSH that a user is required to check fingerprint manually? I mean the following use-case.
There is a server. There is a client. The server provide some personalized services to authenticated users. So it is the server's responsibility to check user's credentials properly.
Server knows its fingerprint. Let's assume that the client (not ssh one, but an app built upon ssh, like a GUI client for git) is unwiling to check the fingerprint because in order to do it it should get the true fingerprint somehow, which means GUI for that has to be implemented.
The authentication protocol is that the client signs the challenge provided by the server, the server verifies it and then allows access. It feels like a design flaw: a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
The way to fix that would be to sign not only challenge, but also server's fingerprint. (See the accepted answer for the right picture) Then the server can detect MiTM server-side. Though it doesn't protect from a malicious server being impersonated to a user.
authentication man-in-the-middle ssh
authentication man-in-the-middle ssh
asked May 13 at 9:02
KOLANICHKOLANICH
461413
asked May 13 at 9:02
KOLANICHKOLANICH
461413
edited May 13 at 13:49
KOLANICH
asked May 13 at 9:02
KOLANICHKOLANICH
461413
asked May 13 at 9:02
KOLANICHKOLANICH
461413
asked May 13 at 9:02
KOLANICHKOLANICH
461413
461413
2
This mechanism is called "Trust on First Use" (TOFU).
– Sjoerd
May 13 at 9:09
Not quite what you asked, but read up on SSH CA as it addresses this problem
– paj28
May 13 at 9:24
1
@SteffenUllrich KOLANICH does propose a new scheme and is basically asking why we're all so stupid to use the current, "broken" tofu/manual-check scheme instead of what he cooked up. Not exactly a duplicate of how to find the hostkey in a trusted manner.
– Luc
May 13 at 10:12
1
@Luc: Oh, I've focused too much on 90% of the question and the title and did not see that the last two sentences had some proposal for change hidden which I did not expected from reading the title and the rest of the body.
– Steffen Ullrich
May 13 at 11:03
1
@SteffenUllrich Agreed, it's a little hidden. I initially missed it and had to edit my answer later. Might be good to edit the question.
– Luc
May 13 at 11:08
|
show 1 more comment
2
This mechanism is called "Trust on First Use" (TOFU).
– Sjoerd
May 13 at 9:09
Not quite what you asked, but read up on SSH CA as it addresses this problem
– paj28
May 13 at 9:24
1
@SteffenUllrich KOLANICH does propose a new scheme and is basically asking why we're all so stupid to use the current, "broken" tofu/manual-check scheme instead of what he cooked up. Not exactly a duplicate of how to find the hostkey in a trusted manner.
– Luc
May 13 at 10:12
1
@Luc: Oh, I've focused too much on 90% of the question and the title and did not see that the last two sentences had some proposal for change hidden which I did not expected from reading the title and the rest of the body.
– Steffen Ullrich
May 13 at 11:03
1
@SteffenUllrich Agreed, it's a little hidden. I initially missed it and had to edit my answer later. Might be good to edit the question.
– Luc
May 13 at 11:08
2
2
This mechanism is called "Trust on First Use" (TOFU).
– Sjoerd
May 13 at 9:09
This mechanism is called "Trust on First Use" (TOFU).
– Sjoerd
May 13 at 9:09
Not quite what you asked, but read up on SSH CA as it addresses this problem
– paj28
May 13 at 9:24
Not quite what you asked, but read up on SSH CA as it addresses this problem
– paj28
May 13 at 9:24
1
1
@SteffenUllrich KOLANICH does propose a new scheme and is basically asking why we're all so stupid to use the current, "broken" tofu/manual-check scheme instead of what he cooked up. Not exactly a duplicate of how to find the hostkey in a trusted manner.
– Luc
May 13 at 10:12
@SteffenUllrich KOLANICH does propose a new scheme and is basically asking why we're all so stupid to use the current, "broken" tofu/manual-check scheme instead of what he cooked up. Not exactly a duplicate of how to find the hostkey in a trusted manner.
– Luc
May 13 at 10:12
1
1
@Luc: Oh, I've focused too much on 90% of the question and the title and did not see that the last two sentences had some proposal for change hidden which I did not expected from reading the title and the rest of the body.
– Steffen Ullrich
May 13 at 11:03
@Luc: Oh, I've focused too much on 90% of the question and the title and did not see that the last two sentences had some proposal for change hidden which I did not expected from reading the title and the rest of the body.
– Steffen Ullrich
May 13 at 11:03
1
1
@SteffenUllrich Agreed, it's a little hidden. I initially missed it and had to edit my answer later. Might be good to edit the question.
– Luc
May 13 at 11:08
@SteffenUllrich Agreed, it's a little hidden. I initially missed it and had to edit my answer later. Might be good to edit the question.
– Luc
May 13 at 11:08
|
show 1 more comment
2 Answers
2
active
oldest
votes
In short: it is not a design flaw. You've just had a misunderstanding of the design.
The authentication protocol is that the client signs the challenge provided by the server, the server verifies it and then allows access.
The client does not sign a challenge provided by the server. Instead the client signs a structure defined in RFC 4252 section 7 which includes as a major component the session identifier. This session identifier itself is a result of the key exchange as described in RFC 4253 section 7.2.
... a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
Since the MITM does not have access to the clients private key it cannot create a new signature with this key. Thus it needs to find a way to make the server accept the original signature by the client. And since the signature depends on the session identifier the MITM would need to establish a SSH connection between client and MITM and another between MITM and server which both have the same session identifier.
But in the Diffie Hellman key exchange the result of the key exchange depends both on client data unknown to the server and server data unknown to the client. Since the MITM has only control over one side of each connection it cannot control the result of the key exchange and thus cannot control the session identifier.
Therefore the attack you describe will not work. The MITM cannot simply impersonate the client as long as the server properly authenticates the client. Either the authentication will fail because the signature is broken (does not match the session identifier) or it will fail because the public key is not the one expected by the server (in case MITM made up its own client key).
answered May 13 at 12:01
Steffen UllrichSteffen Ullrich
124k16217284
Wait so fingerprint checking is not needed if you put a public key on the server already, assuming the server either accepts hostkey authentication only or you are smart enough not to enter your password if the "server" (i.e. a mitm) unexpectedly prompts for it?
– Luc
May 13 at 14:59
3
@Luc I'm fairly certain that connecting to an illegitimate server is still an issue, it's just that that server won't be able to act as a proxy and connect with the correct server. So it's not a MitM really, but it's still a problem.
– AndrolGenhald
May 13 at 15:56
2
@Luc: A scenario where a MITM actively intercepts the connection to the original server is not possible if the client uses key based authentication. But it is still possible that some attacker impersonates a server and simply accepts your key, only he cannot use this then to impersonate you against the real server. This is actually the same with TLS, i.e. both legal and malicious TLS interception are not possible if client certificates are involved, the MITM does not have your client certificate and the server strictly checks your certificate.
– Steffen Ullrich
May 13 at 17:29
add a comment |
Is it a design flaw in SSH that a user is required to check fingerprint manually?
It has pros and cons (surprise!).
Websites use a 'trusted' third party for HTTPS. We all trust the Staat Der Nederlanden, Chunghwa, Atos, and the China Financial Certification Authority to verify your connection between you and your bank, right? Because that's exactly what they're doing, and this has been known to go wrong in the past. But it's the best we got: we can't expect our moms to ring up the bank to ask their fingerprint, so we need to use these semi-trusted certificate authorities.
For SSH, it is mainly used by system administrators or other power users, so it is more reasonable to expect that they check the fingerprint, or at least understand what it is. A security-aware admin can check it, if they wish to do so (for example, I work for an IT security consultancy and we check the fingerprints before connecting). Otherwise, at least it's trust on first use as Sjoerd already mentioned, so it can't just change without you noticing. An attack would have to be present from the start, and has to go on indefinitely, for it to go unnoticed.
It feels like a design flaw: a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
Same with any other scheme, right? You can always MitM and proxy the traffic. In ssh's case you get a wrong fingerprint the first time or a fat alert upon any subsequent connections, and in https' case you get a certificate warning.
The way to fix that would be to sign not only challenge, but also server's fingerprint. Then the server can detect MiTM server-side.
Think this through:
A: Hello there, SSH server of bob.example.com!
B: Greetings, stranger. Here is my public key: abcdef
M: intercepts the message and changes abcdef to 123456
A: Hi server bob with public key 123456, I'm Alice with password bz8iuqw45.
M: intercepts the message and changes 123456 to abcdef
B: Hi Alice! You logged in successfully!
An attacker will use their own public key, so they can decrypt the traffic. When forwarding the data, they can replace the fingerprint. You would have to do mutual authentication, where the client supplies a public key that is already trusted by the server. Only then does the server know for sure that the client is using the right key and is not being man-in-the-middled. But now you reversed the problem: now the server has to know the right fingerprint (of the user's public key) instead of the user of the server. The issue, key distribution, remains.
Let's assume that the client is unwiling to check the fingerprint because in order to do it it should get the true fingerprint somehow.
Do you mean it's impossible to get the fingerprint, without trusting the fingerprint when connecting? Because you could grab the real fingerprint when installing the server, before connecting via ssh.
I feel like some clients don't check fingerprints at all
That would be a vulnerability in the client. If you want to check fingerprints but your client does not support that, then you can't use those clients. It's a little easy to say "the authors of the ssh protocol did it all wrong, this is causing clients to ignore security", because as I said, there are pros and cons to this default scheme. If you want to change it, SSH supports certificate authorities as paj28 mentioned.
answered May 13 at 9:26
LucLuc
24.9k646104
The problem is that Git is built on top of SSH, and I feel like some clients don't check fingerprints at all because the author of the client would have to implement TOFU himself, so he have just disabled this feature. And also TOFU is a usability issue. So as a defence in depth measure, MiTM may be mitigated server-side if the mentioned protocol used.
– KOLANICH
May 13 at 9:29
@KOLANICH I've updated the answer to include a response to your proposed solution.
– Luc
May 13 at 9:38
2
@KOLANICH "Since the auth message will contain attacker's server fingerprint, the benign server would reject that message." Please read my answer again. Any MITM will change the server's fingerprint, so they can decrypt the client's response, change the contents of the response to include the correct fingerprint, and send that to the benign server. That is not the "signature scheme [being] malleable", that is the server and client not knowing each other's keys. Key distribution problem.
– Luc
May 13 at 10:13
1
@Luc for things like Git, the user's public key is often distributed out-of-band to the server (e.g. by uploading it on Github's website). That is what we can build on (and what actually already works, as detailed by the other answer). If the server doesn't know the user's public key, public key authentication won't work at all anyways.
– Paŭlo Ebermann
May 13 at 18:55
1
@KOLANICH: if your concern is actual git and not merely 'like' git, git does not require ssh
– dave_thompson_085
May 14 at 3:40
|
show 6 more comments
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "162"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f210078%2fis-ssh-secure-against-mitm-if-server-fingerprint-is-not-checked-public-key-auth%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
In short: it is not a design flaw. You've just had a misunderstanding of the design.
The authentication protocol is that the client signs the challenge provided by the server, the server verifies it and then allows access.
The client does not sign a challenge provided by the server. Instead the client signs a structure defined in RFC 4252 section 7 which includes as a major component the session identifier. This session identifier itself is a result of the key exchange as described in RFC 4253 section 7.2.
... a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
Since the MITM does not have access to the clients private key it cannot create a new signature with this key. Thus it needs to find a way to make the server accept the original signature by the client. And since the signature depends on the session identifier the MITM would need to establish a SSH connection between client and MITM and another between MITM and server which both have the same session identifier.
But in the Diffie Hellman key exchange the result of the key exchange depends both on client data unknown to the server and server data unknown to the client. Since the MITM has only control over one side of each connection it cannot control the result of the key exchange and thus cannot control the session identifier.
Therefore the attack you describe will not work. The MITM cannot simply impersonate the client as long as the server properly authenticates the client. Either the authentication will fail because the signature is broken (does not match the session identifier) or it will fail because the public key is not the one expected by the server (in case MITM made up its own client key).
answered May 13 at 12:01
Steffen UllrichSteffen Ullrich
124k16217284
Wait so fingerprint checking is not needed if you put a public key on the server already, assuming the server either accepts hostkey authentication only or you are smart enough not to enter your password if the "server" (i.e. a mitm) unexpectedly prompts for it?
– Luc
May 13 at 14:59
3
@Luc I'm fairly certain that connecting to an illegitimate server is still an issue, it's just that that server won't be able to act as a proxy and connect with the correct server. So it's not a MitM really, but it's still a problem.
– AndrolGenhald
May 13 at 15:56
2
@Luc: A scenario where a MITM actively intercepts the connection to the original server is not possible if the client uses key based authentication. But it is still possible that some attacker impersonates a server and simply accepts your key, only he cannot use this then to impersonate you against the real server. This is actually the same with TLS, i.e. both legal and malicious TLS interception are not possible if client certificates are involved, the MITM does not have your client certificate and the server strictly checks your certificate.
– Steffen Ullrich
May 13 at 17:29
add a comment |
In short: it is not a design flaw. You've just had a misunderstanding of the design.
The authentication protocol is that the client signs the challenge provided by the server, the server verifies it and then allows access.
The client does not sign a challenge provided by the server. Instead the client signs a structure defined in RFC 4252 section 7 which includes as a major component the session identifier. This session identifier itself is a result of the key exchange as described in RFC 4253 section 7.2.
... a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
Since the MITM does not have access to the clients private key it cannot create a new signature with this key. Thus it needs to find a way to make the server accept the original signature by the client. And since the signature depends on the session identifier the MITM would need to establish a SSH connection between client and MITM and another between MITM and server which both have the same session identifier.
But in the Diffie Hellman key exchange the result of the key exchange depends both on client data unknown to the server and server data unknown to the client. Since the MITM has only control over one side of each connection it cannot control the result of the key exchange and thus cannot control the session identifier.
Therefore the attack you describe will not work. The MITM cannot simply impersonate the client as long as the server properly authenticates the client. Either the authentication will fail because the signature is broken (does not match the session identifier) or it will fail because the public key is not the one expected by the server (in case MITM made up its own client key).
answered May 13 at 12:01
Steffen UllrichSteffen Ullrich
124k16217284
Wait so fingerprint checking is not needed if you put a public key on the server already, assuming the server either accepts hostkey authentication only or you are smart enough not to enter your password if the "server" (i.e. a mitm) unexpectedly prompts for it?
– Luc
May 13 at 14:59
3
@Luc I'm fairly certain that connecting to an illegitimate server is still an issue, it's just that that server won't be able to act as a proxy and connect with the correct server. So it's not a MitM really, but it's still a problem.
– AndrolGenhald
May 13 at 15:56
2
@Luc: A scenario where a MITM actively intercepts the connection to the original server is not possible if the client uses key based authentication. But it is still possible that some attacker impersonates a server and simply accepts your key, only he cannot use this then to impersonate you against the real server. This is actually the same with TLS, i.e. both legal and malicious TLS interception are not possible if client certificates are involved, the MITM does not have your client certificate and the server strictly checks your certificate.
– Steffen Ullrich
May 13 at 17:29
add a comment |
In short: it is not a design flaw. You've just had a misunderstanding of the design.
The authentication protocol is that the client signs the challenge provided by the server, the server verifies it and then allows access.
The client does not sign a challenge provided by the server. Instead the client signs a structure defined in RFC 4252 section 7 which includes as a major component the session identifier. This session identifier itself is a result of the key exchange as described in RFC 4253 section 7.2.
... a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
Since the MITM does not have access to the clients private key it cannot create a new signature with this key. Thus it needs to find a way to make the server accept the original signature by the client. And since the signature depends on the session identifier the MITM would need to establish a SSH connection between client and MITM and another between MITM and server which both have the same session identifier.
But in the Diffie Hellman key exchange the result of the key exchange depends both on client data unknown to the server and server data unknown to the client. Since the MITM has only control over one side of each connection it cannot control the result of the key exchange and thus cannot control the session identifier.
Therefore the attack you describe will not work. The MITM cannot simply impersonate the client as long as the server properly authenticates the client. Either the authentication will fail because the signature is broken (does not match the session identifier) or it will fail because the public key is not the one expected by the server (in case MITM made up its own client key).
answered May 13 at 12:01
Steffen UllrichSteffen Ullrich
124k16217284
In short: it is not a design flaw. You've just had a misunderstanding of the design.
The authentication protocol is that the client signs the challenge provided by the server, the server verifies it and then allows access.
The client does not sign a challenge provided by the server. Instead the client signs a structure defined in RFC 4252 section 7 which includes as a major component the session identifier. This session identifier itself is a result of the key exchange as described in RFC 4253 section 7.2.
... a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
Since the MITM does not have access to the clients private key it cannot create a new signature with this key. Thus it needs to find a way to make the server accept the original signature by the client. And since the signature depends on the session identifier the MITM would need to establish a SSH connection between client and MITM and another between MITM and server which both have the same session identifier.
But in the Diffie Hellman key exchange the result of the key exchange depends both on client data unknown to the server and server data unknown to the client. Since the MITM has only control over one side of each connection it cannot control the result of the key exchange and thus cannot control the session identifier.
Therefore the attack you describe will not work. The MITM cannot simply impersonate the client as long as the server properly authenticates the client. Either the authentication will fail because the signature is broken (does not match the session identifier) or it will fail because the public key is not the one expected by the server (in case MITM made up its own client key).
answered May 13 at 12:01
Steffen UllrichSteffen Ullrich
124k16217284
answered May 13 at 12:01
Steffen UllrichSteffen Ullrich
124k16217284
answered May 13 at 12:01
Steffen UllrichSteffen Ullrich
124k16217284
answered May 13 at 12:01
Steffen UllrichSteffen Ullrich
124k16217284
124k16217284
Wait so fingerprint checking is not needed if you put a public key on the server already, assuming the server either accepts hostkey authentication only or you are smart enough not to enter your password if the "server" (i.e. a mitm) unexpectedly prompts for it?
– Luc
May 13 at 14:59
3
@Luc I'm fairly certain that connecting to an illegitimate server is still an issue, it's just that that server won't be able to act as a proxy and connect with the correct server. So it's not a MitM really, but it's still a problem.
– AndrolGenhald
May 13 at 15:56
2
@Luc: A scenario where a MITM actively intercepts the connection to the original server is not possible if the client uses key based authentication. But it is still possible that some attacker impersonates a server and simply accepts your key, only he cannot use this then to impersonate you against the real server. This is actually the same with TLS, i.e. both legal and malicious TLS interception are not possible if client certificates are involved, the MITM does not have your client certificate and the server strictly checks your certificate.
– Steffen Ullrich
May 13 at 17:29
add a comment |
Wait so fingerprint checking is not needed if you put a public key on the server already, assuming the server either accepts hostkey authentication only or you are smart enough not to enter your password if the "server" (i.e. a mitm) unexpectedly prompts for it?
– Luc
May 13 at 14:59
3
@Luc I'm fairly certain that connecting to an illegitimate server is still an issue, it's just that that server won't be able to act as a proxy and connect with the correct server. So it's not a MitM really, but it's still a problem.
– AndrolGenhald
May 13 at 15:56
2
@Luc: A scenario where a MITM actively intercepts the connection to the original server is not possible if the client uses key based authentication. But it is still possible that some attacker impersonates a server and simply accepts your key, only he cannot use this then to impersonate you against the real server. This is actually the same with TLS, i.e. both legal and malicious TLS interception are not possible if client certificates are involved, the MITM does not have your client certificate and the server strictly checks your certificate.
– Steffen Ullrich
May 13 at 17:29
Wait so fingerprint checking is not needed if you put a public key on the server already, assuming the server either accepts hostkey authentication only or you are smart enough not to enter your password if the "server" (i.e. a mitm) unexpectedly prompts for it?
– Luc
May 13 at 14:59
Wait so fingerprint checking is not needed if you put a public key on the server already, assuming the server either accepts hostkey authentication only or you are smart enough not to enter your password if the "server" (i.e. a mitm) unexpectedly prompts for it?
– Luc
May 13 at 14:59
3
3
@Luc I'm fairly certain that connecting to an illegitimate server is still an issue, it's just that that server won't be able to act as a proxy and connect with the correct server. So it's not a MitM really, but it's still a problem.
– AndrolGenhald
May 13 at 15:56
@Luc I'm fairly certain that connecting to an illegitimate server is still an issue, it's just that that server won't be able to act as a proxy and connect with the correct server. So it's not a MitM really, but it's still a problem.
– AndrolGenhald
May 13 at 15:56
2
2
@Luc: A scenario where a MITM actively intercepts the connection to the original server is not possible if the client uses key based authentication. But it is still possible that some attacker impersonates a server and simply accepts your key, only he cannot use this then to impersonate you against the real server. This is actually the same with TLS, i.e. both legal and malicious TLS interception are not possible if client certificates are involved, the MITM does not have your client certificate and the server strictly checks your certificate.
– Steffen Ullrich
May 13 at 17:29
@Luc: A scenario where a MITM actively intercepts the connection to the original server is not possible if the client uses key based authentication. But it is still possible that some attacker impersonates a server and simply accepts your key, only he cannot use this then to impersonate you against the real server. This is actually the same with TLS, i.e. both legal and malicious TLS interception are not possible if client certificates are involved, the MITM does not have your client certificate and the server strictly checks your certificate.
– Steffen Ullrich
May 13 at 17:29
add a comment |
Is it a design flaw in SSH that a user is required to check fingerprint manually?
It has pros and cons (surprise!).
Websites use a 'trusted' third party for HTTPS. We all trust the Staat Der Nederlanden, Chunghwa, Atos, and the China Financial Certification Authority to verify your connection between you and your bank, right? Because that's exactly what they're doing, and this has been known to go wrong in the past. But it's the best we got: we can't expect our moms to ring up the bank to ask their fingerprint, so we need to use these semi-trusted certificate authorities.
For SSH, it is mainly used by system administrators or other power users, so it is more reasonable to expect that they check the fingerprint, or at least understand what it is. A security-aware admin can check it, if they wish to do so (for example, I work for an IT security consultancy and we check the fingerprints before connecting). Otherwise, at least it's trust on first use as Sjoerd already mentioned, so it can't just change without you noticing. An attack would have to be present from the start, and has to go on indefinitely, for it to go unnoticed.
It feels like a design flaw: a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
Same with any other scheme, right? You can always MitM and proxy the traffic. In ssh's case you get a wrong fingerprint the first time or a fat alert upon any subsequent connections, and in https' case you get a certificate warning.
The way to fix that would be to sign not only challenge, but also server's fingerprint. Then the server can detect MiTM server-side.
Think this through:
A: Hello there, SSH server of bob.example.com!
B: Greetings, stranger. Here is my public key: abcdef
M: intercepts the message and changes abcdef to 123456
A: Hi server bob with public key 123456, I'm Alice with password bz8iuqw45.
M: intercepts the message and changes 123456 to abcdef
B: Hi Alice! You logged in successfully!
An attacker will use their own public key, so they can decrypt the traffic. When forwarding the data, they can replace the fingerprint. You would have to do mutual authentication, where the client supplies a public key that is already trusted by the server. Only then does the server know for sure that the client is using the right key and is not being man-in-the-middled. But now you reversed the problem: now the server has to know the right fingerprint (of the user's public key) instead of the user of the server. The issue, key distribution, remains.
Let's assume that the client is unwiling to check the fingerprint because in order to do it it should get the true fingerprint somehow.
Do you mean it's impossible to get the fingerprint, without trusting the fingerprint when connecting? Because you could grab the real fingerprint when installing the server, before connecting via ssh.
I feel like some clients don't check fingerprints at all
That would be a vulnerability in the client. If you want to check fingerprints but your client does not support that, then you can't use those clients. It's a little easy to say "the authors of the ssh protocol did it all wrong, this is causing clients to ignore security", because as I said, there are pros and cons to this default scheme. If you want to change it, SSH supports certificate authorities as paj28 mentioned.
answered May 13 at 9:26
LucLuc
24.9k646104
The problem is that Git is built on top of SSH, and I feel like some clients don't check fingerprints at all because the author of the client would have to implement TOFU himself, so he have just disabled this feature. And also TOFU is a usability issue. So as a defence in depth measure, MiTM may be mitigated server-side if the mentioned protocol used.
– KOLANICH
May 13 at 9:29
@KOLANICH I've updated the answer to include a response to your proposed solution.
– Luc
May 13 at 9:38
2
@KOLANICH "Since the auth message will contain attacker's server fingerprint, the benign server would reject that message." Please read my answer again. Any MITM will change the server's fingerprint, so they can decrypt the client's response, change the contents of the response to include the correct fingerprint, and send that to the benign server. That is not the "signature scheme [being] malleable", that is the server and client not knowing each other's keys. Key distribution problem.
– Luc
May 13 at 10:13
1
@Luc for things like Git, the user's public key is often distributed out-of-band to the server (e.g. by uploading it on Github's website). That is what we can build on (and what actually already works, as detailed by the other answer). If the server doesn't know the user's public key, public key authentication won't work at all anyways.
– Paŭlo Ebermann
May 13 at 18:55
1
@KOLANICH: if your concern is actual git and not merely 'like' git, git does not require ssh
– dave_thompson_085
May 14 at 3:40
|
show 6 more comments
Is it a design flaw in SSH that a user is required to check fingerprint manually?
It has pros and cons (surprise!).
Websites use a 'trusted' third party for HTTPS. We all trust the Staat Der Nederlanden, Chunghwa, Atos, and the China Financial Certification Authority to verify your connection between you and your bank, right? Because that's exactly what they're doing, and this has been known to go wrong in the past. But it's the best we got: we can't expect our moms to ring up the bank to ask their fingerprint, so we need to use these semi-trusted certificate authorities.
For SSH, it is mainly used by system administrators or other power users, so it is more reasonable to expect that they check the fingerprint, or at least understand what it is. A security-aware admin can check it, if they wish to do so (for example, I work for an IT security consultancy and we check the fingerprints before connecting). Otherwise, at least it's trust on first use as Sjoerd already mentioned, so it can't just change without you noticing. An attack would have to be present from the start, and has to go on indefinitely, for it to go unnoticed.
It feels like a design flaw: a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
Same with any other scheme, right? You can always MitM and proxy the traffic. In ssh's case you get a wrong fingerprint the first time or a fat alert upon any subsequent connections, and in https' case you get a certificate warning.
The way to fix that would be to sign not only challenge, but also server's fingerprint. Then the server can detect MiTM server-side.
Think this through:
A: Hello there, SSH server of bob.example.com!
B: Greetings, stranger. Here is my public key: abcdef
M: intercepts the message and changes abcdef to 123456
A: Hi server bob with public key 123456, I'm Alice with password bz8iuqw45.
M: intercepts the message and changes 123456 to abcdef
B: Hi Alice! You logged in successfully!
An attacker will use their own public key, so they can decrypt the traffic. When forwarding the data, they can replace the fingerprint. You would have to do mutual authentication, where the client supplies a public key that is already trusted by the server. Only then does the server know for sure that the client is using the right key and is not being man-in-the-middled. But now you reversed the problem: now the server has to know the right fingerprint (of the user's public key) instead of the user of the server. The issue, key distribution, remains.
Let's assume that the client is unwiling to check the fingerprint because in order to do it it should get the true fingerprint somehow.
Do you mean it's impossible to get the fingerprint, without trusting the fingerprint when connecting? Because you could grab the real fingerprint when installing the server, before connecting via ssh.
I feel like some clients don't check fingerprints at all
That would be a vulnerability in the client. If you want to check fingerprints but your client does not support that, then you can't use those clients. It's a little easy to say "the authors of the ssh protocol did it all wrong, this is causing clients to ignore security", because as I said, there are pros and cons to this default scheme. If you want to change it, SSH supports certificate authorities as paj28 mentioned.
answered May 13 at 9:26
LucLuc
24.9k646104
The problem is that Git is built on top of SSH, and I feel like some clients don't check fingerprints at all because the author of the client would have to implement TOFU himself, so he have just disabled this feature. And also TOFU is a usability issue. So as a defence in depth measure, MiTM may be mitigated server-side if the mentioned protocol used.
– KOLANICH
May 13 at 9:29
@KOLANICH I've updated the answer to include a response to your proposed solution.
– Luc
May 13 at 9:38
2
@KOLANICH "Since the auth message will contain attacker's server fingerprint, the benign server would reject that message." Please read my answer again. Any MITM will change the server's fingerprint, so they can decrypt the client's response, change the contents of the response to include the correct fingerprint, and send that to the benign server. That is not the "signature scheme [being] malleable", that is the server and client not knowing each other's keys. Key distribution problem.
– Luc
May 13 at 10:13
1
@Luc for things like Git, the user's public key is often distributed out-of-band to the server (e.g. by uploading it on Github's website). That is what we can build on (and what actually already works, as detailed by the other answer). If the server doesn't know the user's public key, public key authentication won't work at all anyways.
– Paŭlo Ebermann
May 13 at 18:55
1
@KOLANICH: if your concern is actual git and not merely 'like' git, git does not require ssh
– dave_thompson_085
May 14 at 3:40
|
show 6 more comments
Is it a design flaw in SSH that a user is required to check fingerprint manually?
It has pros and cons (surprise!).
Websites use a 'trusted' third party for HTTPS. We all trust the Staat Der Nederlanden, Chunghwa, Atos, and the China Financial Certification Authority to verify your connection between you and your bank, right? Because that's exactly what they're doing, and this has been known to go wrong in the past. But it's the best we got: we can't expect our moms to ring up the bank to ask their fingerprint, so we need to use these semi-trusted certificate authorities.
For SSH, it is mainly used by system administrators or other power users, so it is more reasonable to expect that they check the fingerprint, or at least understand what it is. A security-aware admin can check it, if they wish to do so (for example, I work for an IT security consultancy and we check the fingerprints before connecting). Otherwise, at least it's trust on first use as Sjoerd already mentioned, so it can't just change without you noticing. An attack would have to be present from the start, and has to go on indefinitely, for it to go unnoticed.
It feels like a design flaw: a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
Same with any other scheme, right? You can always MitM and proxy the traffic. In ssh's case you get a wrong fingerprint the first time or a fat alert upon any subsequent connections, and in https' case you get a certificate warning.
The way to fix that would be to sign not only challenge, but also server's fingerprint. Then the server can detect MiTM server-side.
Think this through:
A: Hello there, SSH server of bob.example.com!
B: Greetings, stranger. Here is my public key: abcdef
M: intercepts the message and changes abcdef to 123456
A: Hi server bob with public key 123456, I'm Alice with password bz8iuqw45.
M: intercepts the message and changes 123456 to abcdef
B: Hi Alice! You logged in successfully!
An attacker will use their own public key, so they can decrypt the traffic. When forwarding the data, they can replace the fingerprint. You would have to do mutual authentication, where the client supplies a public key that is already trusted by the server. Only then does the server know for sure that the client is using the right key and is not being man-in-the-middled. But now you reversed the problem: now the server has to know the right fingerprint (of the user's public key) instead of the user of the server. The issue, key distribution, remains.
Let's assume that the client is unwiling to check the fingerprint because in order to do it it should get the true fingerprint somehow.
Do you mean it's impossible to get the fingerprint, without trusting the fingerprint when connecting? Because you could grab the real fingerprint when installing the server, before connecting via ssh.
I feel like some clients don't check fingerprints at all
That would be a vulnerability in the client. If you want to check fingerprints but your client does not support that, then you can't use those clients. It's a little easy to say "the authors of the ssh protocol did it all wrong, this is causing clients to ignore security", because as I said, there are pros and cons to this default scheme. If you want to change it, SSH supports certificate authorities as paj28 mentioned.
answered May 13 at 9:26
LucLuc
24.9k646104
Is it a design flaw in SSH that a user is required to check fingerprint manually?
It has pros and cons (surprise!).
Websites use a 'trusted' third party for HTTPS. We all trust the Staat Der Nederlanden, Chunghwa, Atos, and the China Financial Certification Authority to verify your connection between you and your bank, right? Because that's exactly what they're doing, and this has been known to go wrong in the past. But it's the best we got: we can't expect our moms to ring up the bank to ask their fingerprint, so we need to use these semi-trusted certificate authorities.
For SSH, it is mainly used by system administrators or other power users, so it is more reasonable to expect that they check the fingerprint, or at least understand what it is. A security-aware admin can check it, if they wish to do so (for example, I work for an IT security consultancy and we check the fingerprints before connecting). Otherwise, at least it's trust on first use as Sjoerd already mentioned, so it can't just change without you noticing. An attack would have to be present from the start, and has to go on indefinitely, for it to go unnoticed.
It feels like a design flaw: a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
Same with any other scheme, right? You can always MitM and proxy the traffic. In ssh's case you get a wrong fingerprint the first time or a fat alert upon any subsequent connections, and in https' case you get a certificate warning.
The way to fix that would be to sign not only challenge, but also server's fingerprint. Then the server can detect MiTM server-side.
Think this through:
A: Hello there, SSH server of bob.example.com!
B: Greetings, stranger. Here is my public key: abcdef
M: intercepts the message and changes abcdef to 123456
A: Hi server bob with public key 123456, I'm Alice with password bz8iuqw45.
M: intercepts the message and changes 123456 to abcdef
B: Hi Alice! You logged in successfully!
An attacker will use their own public key, so they can decrypt the traffic. When forwarding the data, they can replace the fingerprint. You would have to do mutual authentication, where the client supplies a public key that is already trusted by the server. Only then does the server know for sure that the client is using the right key and is not being man-in-the-middled. But now you reversed the problem: now the server has to know the right fingerprint (of the user's public key) instead of the user of the server. The issue, key distribution, remains.
Let's assume that the client is unwiling to check the fingerprint because in order to do it it should get the true fingerprint somehow.
Do you mean it's impossible to get the fingerprint, without trusting the fingerprint when connecting? Because you could grab the real fingerprint when installing the server, before connecting via ssh.
I feel like some clients don't check fingerprints at all
That would be a vulnerability in the client. If you want to check fingerprints but your client does not support that, then you can't use those clients. It's a little easy to say "the authors of the ssh protocol did it all wrong, this is causing clients to ignore security", because as I said, there are pros and cons to this default scheme. If you want to change it, SSH supports certificate authorities as paj28 mentioned.
answered May 13 at 9:26
LucLuc
24.9k646104
edited May 13 at 9:50
answered May 13 at 9:26
LucLuc
24.9k646104
answered May 13 at 9:26
LucLuc
24.9k646104
answered May 13 at 9:26
LucLuc
24.9k646104
24.9k646104
The problem is that Git is built on top of SSH, and I feel like some clients don't check fingerprints at all because the author of the client would have to implement TOFU himself, so he have just disabled this feature. And also TOFU is a usability issue. So as a defence in depth measure, MiTM may be mitigated server-side if the mentioned protocol used.
– KOLANICH
May 13 at 9:29
@KOLANICH I've updated the answer to include a response to your proposed solution.
– Luc
May 13 at 9:38
2
@KOLANICH "Since the auth message will contain attacker's server fingerprint, the benign server would reject that message." Please read my answer again. Any MITM will change the server's fingerprint, so they can decrypt the client's response, change the contents of the response to include the correct fingerprint, and send that to the benign server. That is not the "signature scheme [being] malleable", that is the server and client not knowing each other's keys. Key distribution problem.
– Luc
May 13 at 10:13
1
@Luc for things like Git, the user's public key is often distributed out-of-band to the server (e.g. by uploading it on Github's website). That is what we can build on (and what actually already works, as detailed by the other answer). If the server doesn't know the user's public key, public key authentication won't work at all anyways.
– Paŭlo Ebermann
May 13 at 18:55
1
@KOLANICH: if your concern is actual git and not merely 'like' git, git does not require ssh
– dave_thompson_085
May 14 at 3:40
|
show 6 more comments
The problem is that Git is built on top of SSH, and I feel like some clients don't check fingerprints at all because the author of the client would have to implement TOFU himself, so he have just disabled this feature. And also TOFU is a usability issue. So as a defence in depth measure, MiTM may be mitigated server-side if the mentioned protocol used.
– KOLANICH
May 13 at 9:29
@KOLANICH I've updated the answer to include a response to your proposed solution.
– Luc
May 13 at 9:38
2
@KOLANICH "Since the auth message will contain attacker's server fingerprint, the benign server would reject that message." Please read my answer again. Any MITM will change the server's fingerprint, so they can decrypt the client's response, change the contents of the response to include the correct fingerprint, and send that to the benign server. That is not the "signature scheme [being] malleable", that is the server and client not knowing each other's keys. Key distribution problem.
– Luc
May 13 at 10:13
1
@Luc for things like Git, the user's public key is often distributed out-of-band to the server (e.g. by uploading it on Github's website). That is what we can build on (and what actually already works, as detailed by the other answer). If the server doesn't know the user's public key, public key authentication won't work at all anyways.
– Paŭlo Ebermann
May 13 at 18:55
1
@KOLANICH: if your concern is actual git and not merely 'like' git, git does not require ssh
– dave_thompson_085
May 14 at 3:40
The problem is that Git is built on top of SSH, and I feel like some clients don't check fingerprints at all because the author of the client would have to implement TOFU himself, so he have just disabled this feature. And also TOFU is a usability issue. So as a defence in depth measure, MiTM may be mitigated server-side if the mentioned protocol used.
– KOLANICH
May 13 at 9:29
The problem is that Git is built on top of SSH, and I feel like some clients don't check fingerprints at all because the author of the client would have to implement TOFU himself, so he have just disabled this feature. And also TOFU is a usability issue. So as a defence in depth measure, MiTM may be mitigated server-side if the mentioned protocol used.
– KOLANICH
May 13 at 9:29
@KOLANICH I've updated the answer to include a response to your proposed solution.
– Luc
May 13 at 9:38
@KOLANICH I've updated the answer to include a response to your proposed solution.
– Luc
May 13 at 9:38
2
2
@KOLANICH "Since the auth message will contain attacker's server fingerprint, the benign server would reject that message." Please read my answer again. Any MITM will change the server's fingerprint, so they can decrypt the client's response, change the contents of the response to include the correct fingerprint, and send that to the benign server. That is not the "signature scheme [being] malleable", that is the server and client not knowing each other's keys. Key distribution problem.
– Luc
May 13 at 10:13
@KOLANICH "Since the auth message will contain attacker's server fingerprint, the benign server would reject that message." Please read my answer again. Any MITM will change the server's fingerprint, so they can decrypt the client's response, change the contents of the response to include the correct fingerprint, and send that to the benign server. That is not the "signature scheme [being] malleable", that is the server and client not knowing each other's keys. Key distribution problem.
– Luc
May 13 at 10:13
1
1
@Luc for things like Git, the user's public key is often distributed out-of-band to the server (e.g. by uploading it on Github's website). That is what we can build on (and what actually already works, as detailed by the other answer). If the server doesn't know the user's public key, public key authentication won't work at all anyways.
– Paŭlo Ebermann
May 13 at 18:55
@Luc for things like Git, the user's public key is often distributed out-of-band to the server (e.g. by uploading it on Github's website). That is what we can build on (and what actually already works, as detailed by the other answer). If the server doesn't know the user's public key, public key authentication won't work at all anyways.
– Paŭlo Ebermann
May 13 at 18:55
1
1
@KOLANICH: if your concern is actual git and not merely 'like' git, git does not require ssh
– dave_thompson_085
May 14 at 3:40
@KOLANICH: if your concern is actual git and not merely 'like' git, git does not require ssh
– dave_thompson_085
May 14 at 3:40
|
show 6 more comments
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f210078%2fis-ssh-secure-against-mitm-if-server-fingerprint-is-not-checked-public-key-auth%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
This mechanism is called "Trust on First Use" (TOFU).
– Sjoerd
May 13 at 9:09
Not quite what you asked, but read up on SSH CA as it addresses this problem
– paj28
May 13 at 9:24
1
@SteffenUllrich KOLANICH does propose a new scheme and is basically asking why we're all so stupid to use the current, "broken" tofu/manual-check scheme instead of what he cooked up. Not exactly a duplicate of how to find the hostkey in a trusted manner.
– Luc
May 13 at 10:12
1
@Luc: Oh, I've focused too much on 90% of the question and the title and did not see that the last two sentences had some proposal for change hidden which I did not expected from reading the title and the rest of the body.
– Steffen Ullrich
May 13 at 11:03
1
@SteffenUllrich Agreed, it's a little hidden. I initially missed it and had to edit my answer later. Might be good to edit the question.
– Luc
May 13 at 11:08