rsync and SSL

M. Drew Streib dtype at
Thu Sep 20 11:00:46 EST 2001

On Thu, Sep 20, 2001 at 10:47:15AM +1000, Cameron Simpson wrote:
> That way we could do SMTP over SSL etc etc transparently: clients connect,
> say "SSL", if rejected either fall back or fall out, and if accepted
> then away we all go.
> Is there some technical reason for not doing things this way?

Other than an extra couple tcp transmissions, not too many. It does
probably break about all existing protocols though, at least as written,
since the SSL handshake would fall outside of the bounds of the protocol.
Implementing this on SMTP, for instance, would require more than SMTP,
but would be SMTP+SSLoption, which _may_ be fully backwards compatible,
but certainly not "compliant", as it implements non-standard behavior.

Even if the initial request were inside of the bounds of the protocol,
as in "Renegotiate: SSL" as an http header, the followup
handshake and subsequent transmission certainly wouldn't be standard.

This may not bother you from a technical perspective, but might upset
people that are purists at the wire protocol level. It is something
that certainly could be debated, either for an individual protocol,
or across the spectrum. Nothing to stop rsync from implementing something
like this, since it is sort of in charge of its own protocol development...

I'd be interested in seeing an IETF proposal for something like this,
just for public debate.


M. Drew Streib <dtype at> |
FSG <dtype at>    | Linux International <dtype at>
freedb <dtype at>        | SourceForge <dtype at>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url :

More information about the rsync mailing list