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

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