Can someone go over the different flavors of secure FTP? - TCP-IP

This is a discussion on Can someone go over the different flavors of secure FTP? - TCP-IP ; I haven't sniffed Ethernet packets for a long time, please bear with me. On one side I have several IP phones which support some not-well- documented protocol named (and I quote): FTP(S) On the other side I have a Windows ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Can someone go over the different flavors of secure FTP?

  1. Can someone go over the different flavors of secure FTP?

    I haven't sniffed Ethernet packets for a long time, please bear with
    me.

    On one side I have several IP phones which support some not-well-
    documented protocol named (and I quote):

    FTP(S)

    On the other side I have a Windows server (for now, it will be Linux
    later) which needs to be configured to provide the ambiguous FTP(S)
    service to the phone clients.

    Please consider these dialogs:

    http://patriot.net/~ramon/Secure-FTPs.png
    http://patriot.net/~ramon/FileZilla-Secure-FTP.png

    Can someone please explain (or point to) the differences between the 4
    protocols in the first URL above?

    Fell free to tell the audience exactly what is meant by "implicit" and
    "explicit".

    What should I see in a WireShark capture when those protocol sessions
    are being monitored?

    TIA,

    -Ramon

    ps: a useful feature that I found in WireShark is that I can add an
    extra column called "Destination Port".


  2. Re: Can someone go over the different flavors of secure FTP?

    On Jan 17, 2:52 am, Ramon F Herrera wrote:
    > I haven't sniffed Ethernet packets for a long time, please bear with
    > me.
    >
    > On one side I have several IP phones which support some not-well-
    > documented protocol named (and I quote):
    >
    > FTP(S)
    >
    > On the other side I have a Windows server (for now, it will be Linux
    > later) which needs to be configured to provide the ambiguous FTP(S)
    > service to the phone clients.
    >
    > Please consider these dialogs:
    >
    > http://patriot.net/~ramon/Secure-FTP...Secure-FTP.png
    >
    > Can someone please explain (or point to) the differences between the 4
    > protocols in the first URL above?
    >
    > Fell free to tell the audience exactly what is meant by "implicit" and
    > "explicit".
    >
    > What should I see in a WireShark capture when those protocol sessions
    > are being monitored?
    >
    > TIA,
    >
    > -Ramon
    >
    > ps: a useful feature that I found in WireShark is that I can add an
    > extra column called "Destination Port".


    I found this around:

    "Implicit SSL, while discussed in some SSL drafts, was never formally
    adopted in an RFC. It is not recommended by the IETF and its use is
    becoming more and more uncommon."

    Why is Implicit SSL not recommended?

    -Ramon


  3. Re: Can someone go over the different flavors of secure FTP?

    On Jan 17, 12:37 am, Ramon F Herrera wrote:

    > I found this around:
    >
    > "Implicit SSL, while discussed in some SSL drafts, was never formally
    > adopted in an RFC. It is not recommended by the IETF and its use is
    > becoming more and more uncommon."
    >
    > Why is Implicit SSL not recommended?


    Several reasons (note that I'm responding generally, not just for
    FTP):

    1) It makes it impossible to support both SSL and other protocols on
    the same port. To support plaintext as well, a second port must be
    assigned.

    2) It makes it impossible for the client to support SSL but fallback
    to plaintext. (This is usually a bad idea, but not having the option
    to do this is still a minus.)

    2) It makes it impossible to negotiate a version or options before
    initiating SSL.

    3) It makes it impossible for the server to know what certificate the
    client expects to see. (This makes name-based virtual hosting
    impossible.)

    4) It makes debugging much more difficult -- if the client doesn't
    start an SSL negotiation, the server will be unable to let it know
    that this is what it expects.

    5) If SSL is ever obsoleted and replaced with a newer but incompatible
    protocol, the port will have to be changed or SSL support dropped.

    6) The client must send data first, even if the protocol being
    implemented makes the reverse more logical.

    DS

+ Reply to Thread