SSL version used ? - SSH

This is a discussion on SSL version used ? - SSH ; Hi, I use openSSL 0.9.7 and openSSH 3.9p1 on RHEL 4 This version of SSL seems to be able to use SSL v3 (man) How can I be sure to use SSL v3 between two hosts with ssh and putty ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: SSL version used ?

  1. SSL version used ?

    Hi,

    I use openSSL 0.9.7 and openSSH 3.9p1 on RHEL 4
    This version of SSL seems to be able to use SSL v3 (man)
    How can I be sure to use SSL v3 between two hosts
    with ssh and putty ??

    Thanks for your help ...





  2. Re: SSL version used ?

    astalavista writes:
    >I use openSSL 0.9.7 and openSSH 3.9p1 on RHEL 4
    >This version of SSL seems to be able to use SSL v3 (man)
    >How can I be sure to use SSL v3 between two hosts
    >with ssh and putty ??


    SSL and SSH have nothing to do with each other.
    OpenSSH uses cryptographic routines from a library called OpenSSL,
    which also provides an SSL implementation that OpenSSH doesn't use.
    This causes much confusion.

  3. Re: SSL version used ?


    "Jacob Nevins" wrote in message
    news:VwD*dgIir@news.chiark.greenend.org.uk...
    > astalavista writes:
    >>I use openSSL 0.9.7 and openSSH 3.9p1 on RHEL 4
    >>This version of SSL seems to be able to use SSL v3 (man)
    >>How can I be sure to use SSL v3 between two hosts
    >>with ssh and putty ??

    >
    > SSL and SSH have nothing to do with each other.
    > OpenSSH uses cryptographic routines from a library called OpenSSL,
    > which also provides an SSL implementation that OpenSSH doesn't use.
    > This causes much confusion.


    You know, we keep hearing this confusion, which is to a large extent
    reinforced by the software dependency and to a small extent reinforcced by
    the similar names.

    I haven't explored the dependency: How much pain would implementing these
    cryptographic routines as part of OpenSSH directly, instead of taking
    advantage of their presence in OpenSSL, cause? Just how large are they? Do
    the advantages of using the library really justify not having them internal
    and avoid having the software dependency? Or is there some other benefit I'm
    not seeing?




  4. Re: SSL version used ?

    On 2006-06-08, Nico Kadel-Garcia wrote:
    >
    > "Jacob Nevins" wrote in message
    > news:VwD*dgIir@news.chiark.greenend.org.uk...
    >> SSL and SSH have nothing to do with each other.
    >> OpenSSH uses cryptographic routines from a library called OpenSSL,
    >> which also provides an SSL implementation that OpenSSH doesn't use.
    >> This causes much confusion.

    >
    > You know, we keep hearing this confusion, which is to a large extent
    > reinforced by the software dependency and to a small extent reinforcced by
    > the similar names.
    >
    > I haven't explored the dependency: How much pain would implementing these
    > cryptographic routines as part of OpenSSH directly, instead of taking
    > advantage of their presence in OpenSSL, cause?


    More than it would be worth, I would imagine. In addition to the
    symmetric crypto, you would also need the public-key algorithms and the
    bignum functions needed to implement them.

    > Just how large are they?


    For comparison: PuTTY is the only implementation that springs to mind
    which has its both its own crypto implementations and source readily
    available. They are mostly (entirely? I didn't check them all) in
    portable C.

    Picking out the likely looking candidates from the PuTTY source:

    $ wc -l sshbn.c sshaes.c ssharcf.c sshblowf.c sshdes.c sshdh.c sshdss.c \
    sshmd5.c sshprime.c sshrand.c sshrsag.c sshsh*.c
    1087 sshbn.c
    1234 sshaes.c
    123 ssharcf.c
    588 sshblowf.c
    1031 sshdes.c
    230 sshdh.c
    643 sshdss.c
    317 sshmd5.c
    1398 sshprime.c
    246 sshrand.c
    103 sshrsag.c
    269 sshsh256.c
    358 sshsh512.c
    363 sshsha.c
    7990 total

    (Pedants may point out that Portable OpenSSH already has its own AES
    implmentation which is true, however PuTTY doesn't have CAST which
    OpenSSH supports, so it's probably a wash.)

    > Do
    > the advantages of using the library really justify not having them internal
    > and avoid having the software dependency? Or is there some other benefit I'm
    > not seeing?


    OpenSSL has optimized assembler versions for many platforms, crypto hardware
    support (including smartcards), it already exists, it's widely tested...

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

  5. Re: SSL version used ?

    Darren Tucker wrote:
    > For comparison: PuTTY is the only implementation that springs to mind
    > which has its both its own crypto implementations and source readily
    > available. They are mostly (entirely? I didn't check them all) in
    > portable C.


    They should all be, although our definition of `portable' may differ
    from yours - it wouldn't surprise me to learn that OpenSSH compiled
    on some platform or other that nobody had ever tried PuTTY on. (Or,
    conceivably, vice versa.) In particular, we have no interest in
    platforms with 16-bit ints (I don't know whether you do).

    > 1398 sshprime.c
    > 103 sshrsag.c


    (These two are only used in PuTTYgen; if you intended to include key
    generation code as well then you missed sshdssg.c, although it's
    only about the same size as sshrsag.c.)

    > OpenSSL has optimized assembler versions for many platforms, crypto hardware
    > support (including smartcards), it already exists, it's widely tested...


    And my understanding is that it, or some version of it, has been
    FIPS 140-2 certified, which our crypto hasn't. Someone in the US
    government was recently seriously suggesting building a version of
    PuTTY with all our crypto replaced with calls to OpenSSL (!), so
    that it would be usable under US government software certification
    regulations...
    --
    Simon Tatham "A defensive weapon is one with my finger on the
    trigger. An offensive weapon is one with yours."

  6. Re: SSL version used ?

    Simon Tatham wrote:
    > Darren Tucker wrote:
    >> For comparison: PuTTY is the only implementation that springs to mind
    >> which has its both its own crypto implementations and source readily
    >> available. They are mostly (entirely? I didn't check them all) in
    >> portable C.

    >
    > They should all be, although our definition of `portable' may differ
    > from yours - it wouldn't surprise me to learn that OpenSSH compiled
    > on some platform or other that nobody had ever tried PuTTY on. (Or,
    > conceivably, vice versa.) In particular, we have no interest in
    > platforms with 16-bit ints (I don't know whether you do).
    >
    >> 1398 sshprime.c
    >> 103 sshrsag.c

    >
    > (These two are only used in PuTTYgen; if you intended to include key
    > generation code as well then you missed sshdssg.c, although it's
    > only about the same size as sshrsag.c.)
    >
    >> OpenSSL has optimized assembler versions for many platforms, crypto hardware
    >> support (including smartcards), it already exists, it's widely tested...

    >
    > And my understanding is that it, or some version of it, has been
    > FIPS 140-2 certified, which our crypto hasn't. Someone in the US
    > government was recently seriously suggesting building a version of
    > PuTTY with all our crypto replaced with calls to OpenSSL (!), so
    > that it would be usable under US government software certification
    > regulations...


    A bit off topic, I know..

    Simon, please consider keeping things the way they are.. If this is a
    must, please make it a compile time option.

    PuTTY and friends rock, let's keep the boat stable. :-)

    FWIW, I manage 3 mixed OS networks over a VPN using PuTTY (et al) and it
    works flawlessly. So I have a vested interest in the way things work now.

    Craig

  7. Re: SSL version used ?

    Craig Morrison wrote:
    > Simon, please consider keeping things the way they are.. If this is a
    > must, please make it a compile time option.


    Have no fear, the standard PuTTY will continue to use the standard
    PuTTY crypto. What random people in other countries choose to do to
    meet their local certification requirements is no concern of ours.

    > PuTTY and friends rock, let's keep the boat stable. :-)


    A metaphor mixed with pure artistry ;-)
    --
    Simon Tatham "A cynic is a person who smells flowers and
    immediately looks around for a coffin."

+ Reply to Thread