Secure direct-connect file transfer program

Question

I am thinking about doing a side project which would involve transferring files in a standard direct-connect fashion. To clarify, if 9.9.9.9 wanted to send a file to 10.10.10.10, 10.10.10.10 would have be listening on some port and then 9.9.9.9 would be able to connect to 10.10.10.10 using a secure connection.

Unfortunately, I have very little background with any secure protocol, but I recently was reading up on how two-way SSL works. I was thinking of writing this in Python so I can use the Python SSL library.

I am trying to come up with a high level overview of how I would transfer the file. I was thinking of the following:

1) When the program is started up for the very first time, the program will generate a self-signed certificate. This certificate will be used with this program until the certificate expires or is deleted.

2) User A wants to send a file to user B. Let's say they have never transferred files between each other. B will have to have an SSL listen socket on some port already up. A will attempt to connect to B.

3) When A tries to connect to B, both parties will be warned that they have never connected to each other. If both parties choose to continue, they will store each other's certificates on their respective machines. In the future, if A wants to send a file to B or vice versa, the program will not warn them of this since they have each other's certificate.

4) A can now send the file to B.

A couple of questions:

1) Is there anything wrong with the overview (I am sure there is)?

2) In addition to the client having access to the listener's certificate, two-way SSL allows the listener to have access to the client's certificate, correct?

3) What would be a good expiration time limit, if any, for these generated certificates?

Thank you guys very much!

Answer 1

You will find this wrapper program (in C) useful:

• https://www.stunnel.org/

There's a security flaw in your program regarding to the initial exchange of SSL certificates. Your protocol is vulnerable to the man-in-the-middle attack which SSL tries hard to block. Using Diffie-Hellman will improve the situation a little bit but will not essentially solve the problem. This is why all major OS/browsers are shipped with many SSL certificates.

Update

I suggested you to just play with Stunnel because it would be too much work for you to write both of server and client sides from the beginning when you're not sure what you can do with SSL. Stunnel is a feature-complete (including mutual (aka 2-way) auth) and combat-proven example of a OpenSSL user software.

I think you need the following steps:

1. Use Stunnel to connect to https://www.google.com/
2. Use Stunnel to run a local SSL server with your self-signed certificate
3. Use Stunnel to connect to 2.
4. Use Python SSL to connect to 2.
5. Use Python SSL to run a local SSL server with your self-signed certificate
6. Use Python SSL to connect to 5.

Then you will learn what sequence of operations is necessary for your project. I can hardly imagine you would have a problem due to a lack of feature of Stunnel. If you have a problem with Stunnel, it would most likely be an inherent limitation of SSL and you will not be free from it after you switch to Python SSL.

Update 2

It might even be better to start with openssl s_client and openssl s_server than Stunnel. They are a kind of "SSL telnet."