-- James A. Donald:
SSH server public/private keys are widely deployed. PKI public keys are not. Reason is that each SSH server just whips up its own keys without asking anyone's permission, or getting any certificates.
Eric Murray:
..which means that it [ssh-- ericm] still requires an OOB authentication. (or blinding typing 'yes' and ignoring the consequences). But that's another subject.
James A. Donald:
Not true. Think about what would happen if you tried a man in the middle attack on an SSH server.
On 5 Sep 2003 at 10:47, Eric Murray wrote:
you'd get the victim's session:
No you will not, because the "victim"'s ssh client will immediately detect that the uncertified public key is different from the last time he logged in -- which is why he will not be a victim. In practice, certification is only useful for governments to monitor us, which is why so few people use it -- not because they are worried about government monitoring, but because there no benefit in it for the end user. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG iPa66kCgZYuVbwU8o3SYbR0jE6eUaJfpnOK8I7gd 4GzIVQBL8Is5mMcQ0VkDC+3TEoasePfzJK+k+NbRk
On Fri, Sep 05, 2003 at 08:25:50PM -0700, James A. Donald wrote:
Eric Murray:
..which means that it [ssh-- ericm] still requires an OOB authentication. (or blinding typing 'yes' and ignoring the consequences). But that's another subject.
James A. Donald:
Not true. Think about what would happen if you tried a man in the middle attack on an SSH server.
On 5 Sep 2003 at 10:47, Eric Murray wrote:
you'd get the victim's session:
No you will not, because the "victim"'s ssh client will immediately detect that the uncertified public key is different from the last time he logged in
By checking the key against the IP address of the server. This is easily spoofed. The links I included in my last post pointed to a tool to do just that (plus MITM the ssh protocol). But even worse, there is no way to ensure that the key the client has is really the server's key in the first place. The client gets that key the first time it connects....the user is shown a fingerprint of the key and asked to type 'yes' if the user thinks that it's the server's key. What the user is supposed to do here is to have obtained the key or its fingerprint in a secure fashion outside the ssh protocol. But very few people do. They just type 'yes' and accept it. Hence my original statement. This makes a MITM attack easy, the attacker simply needs to have his attack in place when the victim expects the server to have a new key. He gives his key in place of the servers key, the victim never checks, and away we go. Certificates have their own problems, but bare public keys are weak unless your system provides a good useable OOB authentication. SSH as normally used doesn't. Eric
-- James A. Donald:
Think about what would happen if you tried a man in the middle attack on an SSH server.
Eric Murray:
By checking the key against the IP address of the server. This is easily spoofed. The links I included in my last post pointed to a tool to do just that (plus MITM the ssh protocol).
Not it is not.
But even worse, there is no way to ensure that the key the client has is really the server's key in the first place. The client gets that key the first time it connects....the user is shown a fingerprint of the key and asked to type 'yes' if the user thinks that it's the server's key.
For this to happen, the attacker must solicit the the victim to log on to a site he has never logged onto before, or redirect him to logon to a site he has never logged onto before. In this situation, the SSH uncertified public keys work far better than Verisign's certified keys -- for example the spam email urging us to log on to "e-golb.com" or "e-go1d.com" would fail if https used ssh style public keys, because the user would get a "new site" dialog, tipping him off that something was up, and that he should check what is going on. Thus under this attack, ssh uncertified keys work far better than https certified keys.
What the user is supposed to do here is to have obtained the key or its fingerprint in a secure fashion outside the ssh protocol. But very few people do. They just type 'yes' and accept it. Hence my original statement.
Far safer to do that than to rely on https certified keys, as lots of people discovered who logged into "e-go1d.com" or "BankOpAmerica.com"
This makes a MITM attack easy, the attacker simply needs to have his attack in place when the victim expects the server to have a new key.
The victim never expects the server to have a new key, and in the unlikely event he did expect it the out of band mechanism notifying him of the new key is under the sites control, not the attackers. All these attacks that you confidently declare are supposedly so easy on ssh also work against https, and work a great deal better. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG yAguzlpuklHQyVv9VSbkoIWDQYXm/25Gqmt7qnEG 4IYMTLFaNCAaKYXvO9t7lJdAG8LlfXr2/TYbrx58W
On Sat, 6 Sep 2003, James A. Donald wrote:
Thus under this attack, ssh uncertified keys work far better than https certified keys.
Central certification authority has its risks and advantages. Remembering the fingerprints of known keys and alerting for the new or changed ones has its advantages too. Why we shouldn't have it all? Why there couldn't be a system that would keep the database of known keys and report changes and new keys, like SSH does, and at the same give the possibility to sign the keys by several CAs? Effectively turning the hierarchy with potentially vulnerable top to a much-less-vulnerable web structure? That way you could get a key certified by Verisign, Thawte, and a handful of small private CAs of various groups and people, and its fingerprint remembered by the clients. If one of the CAs gets compromised, no problem as the other certificates still hold. If a server key gets changed, or there is a confusion-attack in progress ("BankOpAmerica"), the clients are immediately aware of it. Could be SSL modified to allow more CAs for one certificate? If it isn't a good idea, why?
-- On 7 Sep 2003 at 7:00, Thomas Shaddack wrote:
Central certification authority has its risks and advantages. Remembering the fingerprints of known keys and alerting for the new or changed ones has its advantages too. Why we shouldn't have it all?
Why there couldn't be a system that would keep the database of known keys and report changes and new keys, like SSH does, and at the same give the possibility to sign the keys by several CAs? Effectively turning the hierarchy with potentially vulnerable top to a much-less-vulnerable web structure?
Ideally a client that mediates interactions should get trust information from all relevant sources, and flag the user when there is something unusual about an interaction. However the more sources, the harder it is for mere software to figure out what is meaningful and relevant, and therefore the greater the risk that one will wind up continually throwing irrelevant dialog boxes at the user, which the user eventually learns to click through and ignore. It is hard to do what you propose. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG McThKMMEVOKkdz4RWIcbMuoi2/6QWYqfbndp1rrO 4NHj3GqtByVC9gs20vzoMmlt0cJTw1eJUCwsGHG/S
participants (3)
-
Eric Murray -
James A. Donald -
Thomas Shaddack