filegive
Documentation
Not logged in

Security

Implementation

The code for all the crypto is that included in the go crypto package.

It uses the TLS layer, only using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA.

As for the certificates, it uses a 4096 RSA Certificate Authority (generated with '-g' at any time), and it generates an ephemereal 2048 RSA certificate for every execution of filegive.

It displays the SHA-1 fingerprints of the certificates, to check trust. Moreover, it offers the interactive ('-i') option, that allows acknowledging any file request.

Telling URLs through internet

For the sending to be effective, you have to pass an URL to your colleague. You pass the URLs through a secure channel like with OTR in chat. Or use some way you can trust you tell the URL only to the right person (voice call, etc.)

Checking certificates

Trying to send a file, filegive will tell something like:

Certificate SHA1 (s: filegive qcxpxfad): FA:A2:FB:71:0D:72:F8:95:D4:B3:6B:DC:03:C7:57:20:F8:11:EC:5F
https://77.231.173.13:33009/snuyjn/README

If your colleague receives a file from you for the first time, he will not know whether to trust the certificate of the connection or not. You can check whether he sees the "same Certificate SHA-1" at his side, by chat or voice, so he can chose to trust it. If you don't check it, you could suffer a Man-In-The-Middle.

Adding trust to the CA

Or if you plan to send more files later, he can add trust to the CA. That will avoid any nagging messages about insecure websites. Note that this also makes your colleague capable of making https certificates that your browser will not warn you about; trust the CA only if you trust your friend about that.

To add trust to the CA, you only have to change the URL given by filegive to point to a root "ca.pem" file like this (continuing the example above):

https://77.231.173.13:33009/ca.pem

Firefox, for example, offers a check of the certificate (you can use SHA-1), and tick marks on what to trust. You should choose "trust websites". Then all next sends will be authenticated without nagging dialogs.

For curl, you can check the certificate you downloaded:

$ openssl x509 -in ca.pem -outform DER | openssl dgst -sha1 -c
(stdin)= e6:70:74:3b:33:3a:7c:ee:ca:cd:e9:48:8a:3f:aa:cf:0a:38:15:e2
And then use it in your downloads:
$ curl -O --cacert ca.pem  https://77.231.173.13:33009/snuyjn/README

Note that curl does not support showing the certificate fingerprint yet.

Checking who downloads what

If you want to check if the other side has taken care in the verification of the transmission, you can use the interactive mode ('-i'). Then, you can ask the other side to read you the fingerprints of the certificates, before you accept offering a file to him.

$ filegive -u -i myfile.webm
Certificate SHA1 (s: filegive fjhphdrb): 60:DD:8D:51:60:5A:27:C3:EB:0F:60:E8:CF:7F:A8:4D:26:41:34:94
https://77.231.173.13:37039/cryeip/myfile.webm
New TLS connection from 77.231.173.13:59593 ciphersuite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Accept request from 77.231.173.13:59593 (Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0) (y/n)? y