Aktionen
- Inhaltsverzeichnis
- SSL
SSL¶
- Um SSL für PG-Server zu aktivieren müssen sowohl die postgresql.conf als auch die pg_hba.conf angepasst werden
- Ausserdem wird ein SSL Zertifikat benötigt
SSL Zertifikat¶
- Im Allereinfachsten Fall reicht ein selbstsigniertes Zertifikat
- In diesem Falle wird ist das effektive Ergebniss, dass der Traffic verschlüsselt wird zwischen Server und Client (sofern der Client SSL aushandelt)
- MITM-Attacken werden damit nicht verhindert, da keine Verifizierung des Zertifikates selber gegen Trusted Root-CA stattfinden kann
- In diesem Fall ist es NICHT notwendig den DN des Zertifikates korrekt zu setzen, da dieser ebenfalls nicht verifiziert wird
- Prodat-Mobile, selbstsigniertes Zertifkat erstellen liefert ausführliche Anleitung, welche auch hier zutrifft
- Derzeit ist das Prodat nicht in der Lage zusätzlich zum verschlüsseln des Traffics auch das Zertifikat zu verifizieren
- Prodat benutzt jedoch wenn möglich SSL (TLS1.2) um zu verhindern, dass Passworte (Login) im Klartext über die Leitung gehen
- Im jeweiligen DATA directory des PG-Servers soll dann ein UNterverzeichniss 'ssl' angelegt werden, in welchem die Zertifikats-Dateien abgelegt werden
- Unter Windows DARF das private key file NICHT passphrase protected sein !!!
- Dies bedeutet, diese Datei liegt im Plain-PEM Format vor und der Key ist damit nicht gschützt, daher extra Verzeichniss, damit ACL's sauber darauf gesetzt werden können
- SELECT pg_read_file(current_setting('ssl/ssl_key_file'));
- Dies erlaubt JEDEM superuiser und JEDEM welcher Mitglied der System-Internen Rolle "pg_read_server_files" ist, den privaten key auszulesen !!!
- problematische Rechte:
- SUPERUSER
- pg_read_server_files
- pg_write_server_files
- pg_execute_server_program
- Abgelaufene Zertifikate sind nur dann ein Problem, wenn der Client ein Verify ausführt
- Prodat verifiziiert bislang nicht (kann es nicht)
- PGAdmin verifiziiert bislang nicht
- HeidiSQL verifiziiert bislang nicht, selbst wenn es eingestellt ist
- One important gotcha in PostgreSQL/libpq:
- If a root CA file exists on the client (~/.postgresql/root.crt), then for backward compatibility sslmode=require can behave like verify-ca (i.e., it does validate the server cert chain). In that case, an expired server certificate can suddenly start causing failures even though you thought you weren’t validating.
postgresql.conf¶
ssl = on ssl_cert_file = 'ssl/pgserver.chain' ssl_key_file = 'ssl/pgserver.key' ssl_min_protocol_version = 'TLSv1.2' ssl_max_protocol_version = 'TLSv1.2' ssl_ciphers = 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-SHA:AES256-SHA:!aNULL:!eNULL:!MD5:!RC4:!3DES' ssl_prefer_server_ciphers = on- Prodat-Mobile Anweisung folgend, wäre pgserver.key der "Private Key" und pgserver.chain "Zertifikats-Kette (Chain)"
- Der Rest der Configuratioin muss exakt so eingetragen werden
- Prodat kann derzeit nur OpenSSL 1.0.2 Bibliotheken verwenden, welche maximal TLS1.2 anbieten
- Die aufgelisteten Ciphers stellen sicher, das mit diesem älteren Standard keine unsicheren Verschlüsselungen ausgehandelt werden können
- Unterordner für Zertifikate benutzen, damit ACL's gesetzt werden können, ohne anderes zu beeinflussen
- defaults
pg_hba.conf¶
- Abhängig davon, ob SSL nur erlaubt sein soll oder erforderlich sein soll, muss pg_hba.conf angepasst werden
- Anstatt:
müssen jetzt 2 Zeilen eingetragen werdenhost all root,postgres,SYS.dblink,APPS 0.0.0.0/0 rejecthostssl all root,postgres,SYS.dblink,APPS 0.0.0.0/0 reject # Standard-Super-User restrict by default from outside hostnossl all root,postgres,SYS.dblink,APPS 0.0.0.0/0 reject # Standard-Super-User restrict by default from outside- Jeweils 1 für SSL und eine für ohne SSL
- defaults, SSL erlaubt, nicht erforderlich
Von [E] Rocco Kreutz vor 35 Minuten aktualisiert · 6 Revisionen