search

Luzifer / ots

One-Time-Secret sharing platform with a symmetric 256bit AES encryption in the browser
https://ots.fyi
Apache License 2.0
470 stars 69 forks source link

Add TLS configuration for server #190

Closed hixichen closed 2 months ago

hixichen commented 2 months ago

Currently, the server is configured to use an unsecured HTTP connection via http.ListenAndServe() in the main function. This poses a security risk, particularly for the handleIndex function , which may transmit potentially sensitive personal information over an unencrypted channel.

Rationale:

  1. Data Protection: Implementing TLS encryption will safeguard potentially sensitive information from being intercepted in transit.
  2. Security Best Practices: Using HTTPS is standard for modern web applications, especially those handling personal data.
  3. Mitigation of Man-in-the-Middle Attacks: TLS will help prevent unauthorized access to data through network eavesdropping.
Luzifer commented 2 months ago

Please explain the reasoning behind this PR further. OTS was never intended to be directly exposed to the internet but put behind a TLS terminating ingress / gateway / loadbalancer / proxy: Serve with HTTPs

Why adding TLS support to the server directly? The server should always be shielded by a properly configured LB.

mshedsilegx commented 2 months ago

If I may comment, this idea would be of value for compliance reasons, ie when policies require end to end encryption. In many companies, the LB would not be collocated, so the requirement would be: client -> TLS -> LB -> TLS -> OTS:3000

tchbla commented 2 months ago

If I may comment, this idea would be of value for compliance reasons, ie when policies require end to end encryption. In many companies, the LB would not be collocated, so the requirement would be: client -> SSL -> LB -> SSL -> OTS:3000

this sounds like the legacy on premise design where a centralized LB is used to publish applications from multiple subnets. in that case you use small lb container, like nginx running on the same docker / k8s network in order to process the requests and handle also the TLS (hope SSL is not used in you company anymore :wink:) this also brings extended capabilities for logging and much more a dedicated edge like nginx will

Luzifer commented 2 months ago

Valid points. Hope it doesn't lead too many peeps to expose the Go HTTP server to the public but use a proxy in front of it.

Thank you for your contribution! 🙂

mshedsilegx commented 2 months ago

Yes, TLSv1.2+, corrected. This end to end encryption requirement (LB frontend VIP -> backend) will apply also in the cloud, if using a native cloud LB, so it is not only a "legacy" requirement. Agree, that we should never expose directly the go HTTPS listener externally.