rsync and SSL

Michael H. Warfield mhw at wittsend.com
Fri Sep 21 00:30:33 EST 2001


On Thu, Sep 20, 2001 at 11:11:18AM +1000, Cameron Simpson wrote:
> On Thu, Sep 20, 2001 at 01:00:46AM +0000, M. Drew Streib <dtype at dtype.org> wrote:
> | 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.

> Yeah, but a server not implementing the request should return a 5xx error.
> It's not like the client should proceed with the SSL stuff unless it
> gets a "2xx Yeah I speak SSL." and therefore nothing should break.

> | 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.

> For HTTP you'd return a 4xx or 5xx error of some kind, surely?

> | This may not bother you from a technical perspective, but might upset
> | people that are purists at the wire protocol level.

> Shouldn't if the spec makes sure things don't ascend (descend?) into SSL
> without acceptance on both ends...

> | 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...

> Well, it'd be handy in rsync if only as a proof of concept.

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

> I'll try to find out how to write one and submit it then...

	Check out RFC 2487 [SMTP Service Extension for Secure SMTP over
TLS] and RFC 2995 [Using TLS with IMAP, POP3 and ACAP].  If you want to
do one for rsync you might well model it after the ietf standards that
already exist.

	Considering that rsync itself doesn't even have an RFC, an RFC
for rsync over TLS may well be futile anyways.  IAC...  The first step
would be to propose a working group and get it chartered if there is
enough interest at the ietf.  You don't start out by writing a proposal.

	My guess is that you would have to start with rsync itself first,
if there isn't one already.  I could find nothing in the current drafts
or RFCs to indicate any working group working on rsync.  On that point,
check with Tridge.  It's his baby.

> -- 
> Cameron Simpson, DoD#743        cs at zip.com.au    http://www.zip.com.au/~cs/
> 
> Will Hack Perl for Fine Food and Fun.
> 	- Tom Christiansen <tchrist at cs.colorado.edu>

-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw at WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!





More information about the rsync mailing list