Page MenuHomePhabricator

Security model for session storage service
Open, NormalPublic

Description

We need to establish the security features that make sense for a session storage service, and implement them accordingly (i.e. encryption, access lists, client/server certification verification).

Event Timeline

Eevans created this task.Nov 8 2018, 8:48 PM
Eevans triaged this task as Normal priority.
Eevans added a subscriber: Joe.Feb 11 2019, 7:23 PM

To summarize a (IRC) discussion w/ @Joe today:

  • We most definitely need to TLS encrypt HTTP connections
  • With TLS encryption in place, a certificate trust chain would likely suffice for authentication
  • The use of HTTP basic auth could also work, so long as the Authorization header is encrypted over the wire (see above)
  • A certificate trust chain would technically be more secure, but imposes a significant maintenance burden (maintaining a CA, and (re)issuing signed certs)

Any input from the Security-Team here would be appreciated.

sbassett added a subscriber: sbassett.EditedFeb 12 2019, 4:35 PM

@Eevans, @Clarakosi - just booked a quick hangout with the Security-Team for this Friday (2/15) to discuss potential security concerns for this service.

Change 490106 had a related patch set uploaded (by Eevans; owner: Eevans):
[mediawiki/services/kask@master] Cassandra client encryption

https://gerrit.wikimedia.org/r/490106

Change 490106 merged by Clarakosi:
[mediawiki/services/kask@master] Cassandra client encryption

https://gerrit.wikimedia.org/r/490106

Change 490332 had a related patch set uploaded (by Eevans; owner: Eevans):
[mediawiki/services/kask@master] Cassandra client authentication

https://gerrit.wikimedia.org/r/490332

Change 490332 merged by Clarakosi:
[mediawiki/services/kask@master] Cassandra client authentication

https://gerrit.wikimedia.org/r/490332

Change 491862 had a related patch set uploaded (by Clarakosi; owner: Clarakosi):
[mediawiki/services/kask@master] Kask TLS configuration

https://gerrit.wikimedia.org/r/491862

Change 491862 merged by Eevans:
[mediawiki/services/kask@master] Kask TLS configuration

https://gerrit.wikimedia.org/r/491862

I believe the current status here to be:

  1. Connectivity to session storage will be IP-restricited
  2. We will TLS encrypt the connection between MediaWiki and session storage
  3. We will (eventually) use CA-signed certificates, and validate them
  4. We may move to production (with 1 & 2), and followup with 3 later after sorting out CA particulars

@Joe, @akosiaris does this reflect your opinion as well? I think this issue has remained open to this point in case we needed to implement HTTP basic auth in Kask. If that is not the case, then perhaps we can close this issue?

I believe the current status here to be:

  1. Connectivity to session storage will be IP-restricited
  2. We will TLS encrypt the connection between MediaWiki and session storage
  3. We will (eventually) use CA-signed certificates, and validate them
  4. We may move to production (with 1 & 2), and followup with 3 later after sorting out CA particulars

    @Joe, @akosiaris does this reflect your opinion as well? I think this issue has remained open to this point in case we needed to implement HTTP basic auth in Kask. If that is not the case, then perhaps we can close this issue?

Hi, sorry for the late answer, offsites...

#1 is a bit unclear to me. Yes, the cassandra nodes are IP restricted indeed and only accept connections from the kubernetes pod range. The kubernetes pods range is also IP restricted and only the sessionstore pods can connect to cassandra.

However, anything can currently connect to the sessionstore. IP limiting this is technically possible, however it is going to be a gigantic mess to implement as the mediawiki hosts are NOT some separate network, but rather intermingled with all other hosts. Thus it will require maintaining a list of all mediawiki hosts IP addresses which is very very error prone and tedious (we don't do it for any other service mediawiki connects to either right now).

#2 wise, fully agreed.

#3 wise, we already use CA-signed certificates for the service itself, trusted across our infrastructure. mediawiki hosts already trust it and indeed do verification of certs issued by it (unless I am horribly mistaken, the PHP libraries anyway already do, curl/libcurl definitely do).

So, regarding #4, numbers 2 and 3 are already working anyway, I am not sure if there was an assumption about #1 meaning only mediawiki would be able to connect network wise to the sessionstore.