Scott Bolte
2003-Mar-01 13:25 UTC
encrypt authentication credentials with payload in the clear?
Is it possible to use encryption only for authenticate and then switch to no encryption? I've looked at the code for OpenSSH 3.5p1, cipher.c, and it looks like the answer is no, at least for protocol 1. However, I cannot tell if that is a deliberate design limitation of the implementation or if it is inherent in ssh protocol 2. My dilemma is a customer who wants to use their network IDS to monitor all traffic. I can have a VPN tunnel to the edge of their network, but from that point on they want the traffic in the clear so they can monitor it. Does anyone know of a technique that would let me satisfy the customer's requirements? Thank you, Scott
Markus Friedl
2003-Mar-01 14:09 UTC
encrypt authentication credentials with payload in the clear?
On Sat, Mar 01, 2003 at 07:25:23AM -0600, Scott Bolte wrote:> Is it possible to use encryption only for authenticate and > then switch to no encryption? I've looked at the code for > OpenSSH 3.5p1, cipher.c, and it looks like the answer is > no, at least for protocol 1. However, I cannot tell if that > is a deliberate design limitation of the implementation or > if it is inherent in ssh protocol 2.you could hack openssh to do rekeying for none-encryption. would be about ~20 lines of code.
Scott Bolte
2003-Mar-01 20:41 UTC
encrypt authentication credentials with payload in the clear?
On Sat, 1 Mar 2003 15:09:01 +0100, Markus Friedl wrote:> > > Is it possible to use encryption only for authenticate and > > then switch to no encryption? ... > > you could hack openssh to do rekeying for none-encryption. > > would be about ~20 lines of code.Would you accept such a change and incorporate it back into the standard code base? Scott
Ben Lindstrom
2003-Mar-01 22:31 UTC
encrypt authentication credentials with payload in the clear?
No. - Ben On Sat, 1 Mar 2003, Scott Bolte wrote:> On Sat, 1 Mar 2003 15:09:01 +0100, Markus Friedl wrote: > > > > > Is it possible to use encryption only for authenticate and > > > then switch to no encryption? ... > > > > you could hack openssh to do rekeying for none-encryption. > > > > would be about ~20 lines of code. > > Would you accept such a change and incorporate it back into > the standard code base? > > Scott > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >
Scott Bolte
2003-Mar-02 00:22 UTC
encrypt authentication credentials with payload in the clear?
> On Sat, 1 Mar 2003, Scott Bolte wrote: > > > On Sat, 1 Mar 2003 15:09:01 +0100, Markus Friedl wrote: > > > > > > > Is it possible to use encryption only for authenticate and > > > > then switch to no encryption? ... > > > > > > you could hack openssh to do rekeying for none-encryption. > > > would be about ~20 lines of code. > > > > Would you accept such a change and incorporate it back into > > the standard code base? > > > > ScottOn Sat, 1 Mar 2003 16:31:45 -0600 (CST), Ben Lindstrom wrote:> > No. > > - BenWhy not? Network managers that want to run NIDS can hardly be unique. As long as users are comfortable with their traffic being visible, having the authorization exchange protected is a major step up from the traditional rsh. Scott
Scott Bolte
2003-Mar-04 01:09 UTC
encrypt authentication credentials with payload in the clear?
On Mon, 03 Mar 2003 09:45:05 -0500, James Dennis wrote:> > Shouldn't the IDS be detecting known attacks, not ssh traffic?Their concern is that the traffic, which will be remote service commands by the way, is completely opaque to them. They feel they need to monitor the internals to make sure it is appropriate traffic and not an unknown 3rd party using the cloak of encryption to hide inappropriate actions.> SSH is not rsh. What users would be comfortable with the traffic being > visible?!? If thats what you _really_ want, maybe look into telnet with > kerberos.What I'm trying to do is standardize on ssh, which is fine with most customers. For those that want to monitor traffic internals, I want to still use my ssh infrastructure, albeit with no encryption after the authorization is complete. I realize it is an odd situation, but I'm not in a position to refuse the customer's insistence. Scott
Scott Bolte
2003-Mar-05 02:39 UTC
encrypt authentication credentials with payload in the clear?
On Tue, 4 Mar 2003 10:16:11 -0600 (CST), Ben Lindstrom wrote:> > Stupidity comes in many forms. By weakening their security they think > they are improving it. ...I agree that they are taking a risk in this case. However, they do have a point. When all traffic is encrypted, it benefits those with malicious intent as much as legitimate users. Statistical process controls to detect aberrant behavior is pretty weak detection.> <shrug> Do what most sane people do. Discuss the concept of a basin. So > at least your encrypted all the way into their network. Then you can use > whatever bridge method you like from there.Sorry, I thought I had mentioned that earlier. That is what we do. Connections from our network to their network is over VPN. It is only after we surface from the VPN concentrator on their network that the ssh encryption becomes an issue. Scott P.S. Btw, an interesting set of observations wrt privacy can be found in David Brin's "The Transparent Society" (http://www.kithrup.com/brin/tschp1.html) A must read for anyone interested in issues of privacy.
Loomis, Rip
2003-Mar-05 14:47 UTC
encrypt authentication credentials with payload in the clear?
> I can't help but feel like if you want to watch the traffic > of people's ssh session then you are already hacked.In some realms, particularly financial institutions, there's a requirement that all network traffic in/out of corporate "desktop type" networks must be collected -- so that the institution can prove what it knew when. Think "insider trading" as well as proprietary data. However, most of those organizations don't use SSH in or outbound. In my experience the folks with those sorts of requirements who outsource some of their server/network operations or monitoring provide a separate dedicated network connection for the outsourcing folks, or use a "basin" as Ben already mentioned (although I've heard it called other things). If SSH did support a mode where authentication information was encrypted but terminal sessions were not, it would satisfy a real world requirement IMHO. What's not clear, though, is whether that requirement is worth satisfying in the "stock" portable OpenSSH.> I feel like sending traffic cleartext is just a bad idea accross the > board. What if someone su's or logs into other systems or exposes > database account credentials to something containing personal info > and/or credit card numbers from those cleartext ssh sessions?!?That's a valid concern--as I said, though, the places that want this sort of functionality generally have a good reason (either legal, or based on a full-up risk and threat assessment) why they want to collect it. It might seem strange, but it does happen. -- Rip Loomis Senior Systems Security Engineer, SAIC Enterprise Security Solutions Brainbench MVP for Internet Security | http://www.brainbench.com
Ed Avis
2003-Mar-06 08:09 UTC
encrypt authentication credentials with payload in the clear?Re:
James Dennis <jdennis at law.harvard.edu> wrote: [unencrypted traffic after initial authentication]>If this is what they want, why use ssh?Even if you don't want encryption, ssh is a much better choice than telnet or rsh or any other alternative. The ssh and sshd code is maintained and checked for buffer overruns and other security holes unrelated to eavesdropping or hijacking a connection. I don't think there is any decent implementation of telnetd or rshd still maintained, even if there once was, because all the people who care about security switched to ssh long ago. Apart from security there are also convenience reasons to prefer unencrypted-ssh over telnet or rsh - the user interface of the ssh client is familiar, it supports port forwarding, only one daemon to run instead of two (if you had ssh for encrypted and telnet for unencrypted connections), and so on. Please take it as a compliment that people are keen to use ssh and sshd even without the added security provided by encrypting all traffic. Given that ssh long had a 'fall back to rsh' option I don't think it's too unreasonable to ask for the ssh protocol with no encryption, which will still be far better than running a crusty old rshd. -- Ed Avis <ed at membled.com>
Scott Bolte
2003-Mar-06 13:11 UTC
encrypt authentication credentials with payload in the clear?
On Wed, 5 Mar 2003 09:47:19 -0500, "Loomis, Rip" wrote: ...> If SSH did support a mode where authentication information was > encrypted but terminal sessions were not, it would satisfy a > real world requirement IMHO. What's not clear, though, is whether > that requirement is worth satisfying in the "stock" portable > OpenSSH. > > ... > > That's a valid concern--as I said, though, the places that want > this sort of functionality generally have a good reason (either > legal, or based on a full-up risk and threat assessment) why they > want to collect it. It might seem strange, but it does happen.One reason I really want it in the 'stock' OpenSSH is because it enables a migration path. We can satisfy an organization who's current mindset requires monitorable traffic. Then, as we educate them as to the risks they are taking, and address their other requirements in a more elegant manner, we move them towards a more secure use of ssh. Scott
Scott Bolte
2003-Mar-06 13:18 UTC
encrypt authentication credentials with payload in the clear?
On Wed, 05 Mar 2003 21:23:15 -0600, Nick Lange wrote:> Afternoon everyone, > If everyone is entirely concerned about innocuous commands comming over > the ssh session to the shell account, why > not just analyze the shell logs for analysis there?Shell access needs to go away IMHO. It is too easy to defeat audit trails if there is unfettered shell access. The long term direction I am trying to go is role based access controls using sets of public/private keys which gain access to a proxy command system. That would allow more reliable logging, with excellent access management, without having to worry about all the end cases a shell entails. Scott
Scott Bolte
2003-Mar-06 13:24 UTC
encrypt authentication credentials with payload in the clear?
On Wed, 05 Mar 2003 09:25:43 -0500, James Dennis wrote:> > If this is what they want, why use ssh? Using SSH here will almost > definitly create a false sense of security for people who aren't > entirely sure whats going on. "Oh, our logins are encrypted? Cool." as > they probably would't know the entire session can be encrypted.Why use ssh? Because ssh definitely takes me where I want to go. As I said in a separate message, I want to use forced commands and public/private keys. As I work towards that sophisticated and secure capability, I need stop-gap measures to buy time to educate those organizations with a heavy reliance on NIDS.> I feel like sending traffic cleartext is just a bad idea accross the > board. What if someone su's or logs into other systems or exposes > database account credentials to something containing personal info > and/or credit card numbers from those cleartext ssh sessions?!? ...That's why I want to use forced commands which gain access to a set of proxy services. The proxies will preclude the inadvertent su, or the bare download of sensitive data. Scott
David M. Williams
2003-Mar-13 20:44 UTC
encrypt authentication credentials with payload in the clear?
Something for those in this conversation to note: Proposed language to update the Security Conciderations section of the core IETF drafts in the secsh-WG, (I added the underlining) 11.1 Confidentiality This protocol does allow the encryption mechanism to be disabled. Implementors _SHOULD be wary of exposing this_ _feature for any purpose other than debugging_. Users and administrators _SHOULD be explicitly warned anytime the_ _"none" method is enabled_. Dave -- David M. Williams, CISSP Phone: 505-665-8062 Systems Engineer, CCN-2 Fax: 505-667-7428 Los Alamos National Laboratory Email: d_wllms at lanl.gov