FYI: SSH1 now disabled at compile-time by default

[Michael Felt]

I mentioned extensions because I had a few and saw them die.
the 40-bit ssl is the web interface for power5 (the so-called ASMI https
interface). These ports have no access to "outside", on a separate lan
segment. my desktop, not acting as router, can connect to non-Natted and
NATted segments.

re: use of a stunnel - how does this turn 40-bit https into >40-bit https.
Sounds like a man-in-the-middle I do not want to know about (but should
learn about just the same - aka the sand is not so deep I can bury my head
completely :)
On Mar 27, 2015 2:37 PM, "Hubert Kario" <hkario at redhat.com> wrote:

> On Friday 27 March 2015 14:15:47 Gert Doering wrote:
> > Hi,
> >
> > On Fri, Mar 27, 2015 at 12:53:05PM +0100, Hubert Kario wrote:
> > > On Thursday 26 March 2015 11:19:28 Michael Felt wrote:
> > > > Experience: I have some hardware, on an internal network - that only
> > > > supports 40-bit ssl. I am forced to continue to use FF v17 because
> that
> > > > was
> > > > the last browser to provide SSL40-bit support. My security is
> weakened
> > > > because I cannot update that browser, and I continue to lose plugins
> > > > because they do not support FF17 anymore. All other browsers stopped
> > > > support earlier as well.
> > >
> > > Please put the device behind a stunnel and don't put yourself at risk.
> >
> > I don't think Michael is accessing that device over the Internet - but
> even
> > *in house* some devices force you to jump through such hoops.
>
> the fact that he mentions usage of extensions, I'm not so sure he uses it
> only
> for internal out-of-band management sites...
>
> > Like, old HP ILO that you can't get updates for, that insist on using
> SSL,
> > but then fail to interoperate with recent browsers.  So what are you
> going
> > to do?  "Throw away a perfectly working and secure machine, because its
> > out of band interface is crap" or "keep around an old and insecure
> browser"?
>
> such interfaces should be on a network of their own, as such you should go
> through a router to be able to connect to them. On same router you can put
> the
> stunnel or a redirect to other machine that does the tunneling to make sure
> the insecure connections from trusted network are not routed over regular
> network (be it company internal or Internet)
>
> > Same thing with needing sshv1 to access old network gear where even sshv1
> > was an achievement.  "Throw away gear that does its job perfectly well,
> > but has no sshv2 for *management*" or "keep around an ssh v1 capable
> > client"?
>
> If you depend on hardware like this, you should have support* for it.
> Exactly
> because issues like this.
>
>  * - where "support" means that either you have other people responsible
> for
> fixing it or that you can hire other people to fix it as the need arises
> --
> Regards,
> Hubert Kario