Is there any bandwidth overhead on using SSL on a TCP connection? I understand, of course, the processing/memory usage overhead in encrypting and decrypting packets, but as far as bandwidth is concerned, what is the difference, if any?
For example, given a XML file which is 64KB, will there be any tangible difference in the transfer size of the file over HTTP vs. HTTPS? (Ignoring mod_deflate and mod_gzip, of course)
Some, but mostly just for the negotiation phase. Once you're past that, the bandwidth performance is close to 1:1.
The algorithms used all (I think all.. correct me if I'm wrong) transform the data, keeping the same size between the input and the output.
The one caveat here is that the ciphers have a specific "block size", which is the size each data chunk must be to be encrypted; junk data will be inserted for padding if the message isn't large enough. These block sizes are very small (as big as they get is RSA, where the message size equals the key size, so 1-2 kilobits, but that's just for the handshake), but are a potential source of overhead when dealing with lots of small messages.
Packet payload is reduced due to overhead. SSL encryption key size also is a factor. The larger the key, the greater the processing power required for the sake of security.
To test SSL, use SCP to copy a file via SSH or SFTP to a server. Now try the same copy as FTP. I recommend that you use RSYNC via SSH then RSYNC as a daemon (no encryption).
Purchase an SSL accelerator for your server if SSL processing is a factor.