duplicity SSL performance to Amazon S3

I just rediscovered (and may now try to fix) duplicity bug 433970, which is basically pointing out that using SSL to talk to Amazon S3 within duplicity gives you about 6x less sustained throughput than using plain http. It’s quite an interesting result, and potentially has some consequences for Launchpad, which serves just about everything over ssl and is not as fast as one might like.

Using SSL is a bit redundant because the duplicity backups are typically gpg-encrypted anyhow. I think, without this, the worst exposure would be that people on the network between you and S3 could see that you were using duplicity, the bucket name, and the timestamps of your previous backups.

I’m not sure what the actual cause is, and it may not be directly comparable to lp. I certainly see a lot of upstream traffic as, I suppose, the client does SSL-level synchronization. It may well be something about this particular implementation either on the client or Amazon side.