Date: Mon, 18 Dec 2000 11:06:37 +0100 From: Szilveszter Adam <sziszi@petra.hos.u-szeged.hu> To: freebsd-security@freebsd.org Subject: Re: dsniff 2.3 info: Message-ID: <20001218110637.D6395@petra.hos.u-szeged.hu> In-Reply-To: <Pine.BSF.4.21.0012172347240.48779-100000@security1.noc.flyingcroc.net>; from todd@flyingcroc.net on Sun, Dec 17, 2000 at 11:48:55PM -0800 References: <Pine.BSF.4.21.0012172347240.48779-100000@security1.noc.flyingcroc.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 17, 2000 at 11:48:55PM -0800, Todd Backman wrote: > > FYI: > > The End of SSL and SSH? > > Yesterday, dsniff 2.3 was released. Why is this important, you ask? dsniff > 2.3 allows you to exploit several fundamental flaws in two extremely > popular encryption protocols, SSL and SSH. SSL and SSH are used to protect > a large amount of network traffic, from financial transactions with online > banks and stock trading sites to network administrator access to secured > hosts holding extremely sensitive data. Could this singal the end of SSH > or SSL? > > Read the full story here: > http://securityportal.com/cover/coverstory20001218.html Hi! I have read the article and here are my thoughts about it: - First, this is nothing new, as the author also states. - Second, it requires raw access to the wire, which may or may not be available. Of course it probably will be in your typical university comp lab or if you are on Ethernet otherwise. Now let's consider the scenario that the author presents us with. This involves a man-in-the-middle-attack where the only thing the attacker does is that she intercepts the messages on the wire and always re-encrypts them and then passes them on. This scenario assumes that the parties have no way of knowing who the other party is other than what they say they are and also that they have not been in contact before. This will be most probably true for SSL transactions, especially if the server's CA is self-signed but anyway for the user side. So if you are using SSL connections for things other than say read your highly precious junk email from a free provider, you should consider other options. Also, many banks are now implementing personal certificates which they will pass to the client in a secure (ie off-line either personally or via snail-mail) way. Smart card readers are also more and more wide-spread in these settings. I think we will see people use personal certificates more often in other places too. (eg our national student ID card system in Hungary is a step in that direction. Countries where people are not used to carrying identification with themselves usually face a harder situation.) For SSH however, I see the problem to be not as big. If you are unsure, you can always check if the server's public key is what you think it is. Eg you can ask by phone, it can be on a web page etc. People normally use SSH to places that they are at least to some extent familiar with, eg your mail server. Also, the scenario described does require a constant spoofing, because as soon as the attacker gets out of the way, you will discover there is a problem. Of course, that will not help you a bit in what has already been intercepted but at least you can take action to mitigate the damage. Also, using passwords on SSH may be a good idea. Of course, session-level encryption is a useful idea and should be used whenever possible. Also, educating users about possible dangers is important. Good network design and monitoring is also essential (but we all know this already, right?:-) And you must always evaluate what your security needs are. It is possible that the application is so sensitive that you cannot place it on a network at all. It is possible that you must force use in local network only. etc. As for injecting commands, well, this may be dangerous as far deleting all the files in your home dir goes, but root should never be caught unaware because, if you are root, and you see that the server's public key has changed, you must know there is something going on since you did not do anything to change it! Yes, this involves also regular monitoring of your . files etc. BTW dsniff 2.3 is already available in NetBSD pkgsrc. I think I will go and play with it for a while now:-) As far as upgrading to SSH2 goes, it is only a temporary solution as the author also notes. But, as long as people cannot be bothered to use SSH instead of telnet even when they are hundreds of kms from here over the public Internet and give out their credit card details in the clear and choose their dog's name as password we have other problems to worry about... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001218110637.D6395>