Difference between ssl_context options in Python Flask

Question

In order to support https in Python Flask, one has to specify the ssl_context option on the app.run() command.

It is documented as such:

ssl_context – an SSL context for the connection. Either an ssl.SSLContext, a tuple in the form (cert_file, pkey_file), the string 'adhoc' if the server should automatically create one, or None to disable SSL (which is the default).

Here are the enumerated options:

1. ssl.SSLContext - requires cert and key files.
2. a tuple in the form (cert_file, pkey_file) - requires cert and key files.
3. the string 'adhoc' - seems very simple.

What is the difference between those options in these contexts:

1. User experience
2. Installation of extra modules and files
3. Security

Answer 1

3. Security is the only one that matters, and the answer is "never use the Werkzeug/Flask dev server in production." The ssl_context option is there for convenience during testing, but a production application should use real application and web servers such as uWSGI along with Nginx, configuring Nginx appropriately to present a real TLS certificate.

Answer 2

With first two options, you provide a certificate of your own, that might (should) be either signed by a recognized authority or by your client if you manage them (this happens either if your application is deployed in a context where you can install your certificate on each computer or if your client is not a web browser but your application and you can ship the certificate with it).

This will show the user he is communicating with the real server, not with someone trying to eavesdrop the traffic.

The third option will create a self-signed certificate, offering no guarantee to the user on that matter.

In terms of user experience, using a self-signed certificate when the client is a Web browser will raise a worrying message about the certificate validity, and saying something like "serious web sites would not ask you to blindly accept an unknown certificate".

To sum-up, you have three options (your options 1 & 2 are the same in the end):

• option 1 & 2 with a certificate signed by a recognized authority: the only good solution for a public Web application / Web site.
• option 1 & 2 with a certificate of your own (or signed by an authority of your own), deployed on every client: a good solution when you can install the certificate on each client. A poor solution if you have to ask your clients to do so.
• option 3: a good solution for testing in a lab. A terrible solution in any other context I can think of.