Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- centos:web_c7:apache_2 [28.11.2016 14:08. ] – django
+++ centos:web_c7:apache_2 [02.02.2018 09:39. ] (aktuell) – Löschen von falschen HPKP-Daten beim Browser Firefox django
@@ Zeile 263: / Zeile 263: @@
 ===== Dokumentation =====
 ==== Fachliteratur ====
-Das Buch **[[https://www.feistyduck.com/books/bulletproof-ssl-and-tls/|Bulletproof SSL and TLS]]** von **[[http://blog.ivanristic.com/|Ivan Ristić]]** bringt viele wertvoller Erklärungen und kann jedem interessierten Webmaster wärmstens empfohlen werden! Neben den Grundlagen zu SSL/TLS und PKI finden sich dort auch weiterführende Konfigurationsbeispiele unter anderem zu unserem **//Apache-Webserver 2.4//**. Außerdem erhält man als registrierter Leser wervolle aktulisierte News in Form von regelmäßigen eMails, in denen aktuellste Enticklungen und Schwachstellen beleuchtet werden. Also alles in allem sehr gut angelegte 55€ - das Buch **978-1-907117-04-6** (ISBN) ist in jedem gut sortierten Buchhandel vor Ort erhältlich sein sollte.
+<WRAP center round tip 90%>
+Das Buch **[[https://www.feistyduck.com/books/bulletproof-ssl-and-tls/|Bulletproof SSL and TLS]]** von **[[http://blog.ivanristic.com/|Ivan Ristić]]** bringt viele wertvoller Erklärungen und kann jedem interessierten Webmaster wärmstens empfohlen werden! Neben den Grundlagen zu SSL/TLS und PKI finden sich dort auch weiterführende Konfigurationsbeispiele unter anderem zu unserem **//Apache-Webserver 2.4//**. Ausserdem erhält man als registrierter Leser wertvolle aktualisierte News in Form von regelmässigen eMails, in denen aktuellste Entwicklungen und Schwachstellen beleuchtet werden.
+Also alles in allem sehr gut angelegte 55€ - das Buch **978-1-907117-04-6** (ISBN) ist in jedem gut sortierten Buchhandel vor Ort erhältlich sein sollte.
+</WRAP>
 ==== Seiten im WWW ====
@@ Zeile 625: / Zeile 630: @@
 .0.1e                                    2013-02-11                               DHPARAM(1)
 </code>
+==== Apache.org ====
+Viele wervolle Hinweise zu den Konfigurationsparameter zu **mod_ssl** findet man in der Dokumentation zum [[http://httpd.apache.org/docs/current/mod/mod_ssl.html|Apache Module mod_ssl]] und [[http://httpd.apache.org/docs/current/ssl/ssl_howto.html|SSL/TLS Strong Encryption How-To]].
 ===== CA Trust =====
 Dreh- und Angelpunkt bei den CAs und den zugehörigen Root-Zertifikaten ist das Vertrauen, welches man diesen schenken ma und/oder kann. Mit sehr hoher Wahrscheinlichkeit kann man davon ausgehen dass eine CA wie z.B. **[[https://www.swisssign.com/de/|swiss sign]]** die von den Browserherstellern geforderten Sicherheitsprüfungen erfüllen. Eine wesentliche Schwachstelle der ganzen CAs ist aber, wer garantiert, dass nicht eine x-beliebige zweite CA ein Zertifikat für z.B. **nausch.org** erstellt, obwohl bereits //GlobalSign// hierzu ein X.509-Zertifikat ausgestellt hat?
@@ Zeile 630: / Zeile 640: @@
 <WRAP center round important 85%>
 Ein Umstand, den sich z.B. alle [[https://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff|Man-in-the-Middle-Angriffe]] zu nutze machen und unberechtigter Weise falsche Zertifikate ausstellen und somit dem sorglosen Endanwender in betrügerischer Art und Weise einen gefälschte Identität und eine nicht mehr existierende Ende zu Ende Verschlüsselung zwischen dem Webserver und Browser vorgaukeln.
+</WRAP>
 Wir werden später noch Lösungen aufzeigen, wie wir zum einen auf Serverseite diese betrügerischen Angriffsversuche serverseitig soweit wie möglich zu unterbinden und auch auf Clientseite Lösungen aufzeigen, wie ein Kunde am Browser sehr leicht feststellen kann, ob die Verbindung sicher ist, oder ob jemand mit krimineller Energie versucht an vertrauliche Informationen durch einen MitM-Angriff zu kommen!
-</WARP>
 {{page>centos:ca-trust&nofooter&showheader}}
@@ Zeile 1511: / Zeile 1521: @@
 Im folgenden Schritt zu unserem eigenen Zertifikat erzeugen wir einen **CSR**((**C**ertificate **S**igning **R**equest)), den wir dann in einem weiteren Schritt von unserer eigenen CA signieren lassen werden, oder bei der ausgewählten **kommerziellen CA** einkippen.
-<WRAP round alert> **__Wichtig__**: Bei unserem Serverzertifikat ist der **Common Name** von entscheidender Bedeutung. Hier muss der DNS-Name unseres Dovecot-Servers eingetragen werden, unter dem der Mailserver angesprochen wird!</WRAP>
+<WRAP round alert> **__Wichtig__**: Bei unserem Serverzertifikat ist der **Common Name** von entscheidender Bedeutung. Hier muss der DNS-Name unseres Apache-WebServers bzw. des vHosts eingetragen werden, unter dem der Webserver später angesprochen wird!</WRAP>
 Auch hier sind die Eingaben in der Farbe <html><font style="color: rgb(0, 0, 255)"><b>blau</b></font></html> und die Rückmeldungen in der Farbe <html><font style="color: rgb(0, 0, 0)"><b>schwarz</b></font></html> gekennzeichnet.
@@ Zeile 1802: / Zeile 1812: @@
 ├── cert.pem -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
 ├── certs
 │   ├── ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
 │   ├── ca-bundle.trust.crt -> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
 │   ├── localhost.crt
 │   ├── make-dummy-cert
 │   ├── Makefile
 │   └── renew-dummy-cert
 ├── misc
 │   ├── CA
 │   ├── c_hash
 │   ├── c_info
 │   ├── c_issuer
 │   └── c_name
 ├── openssl.cnf
 └── private
@@ Zeile 1826: / Zeile 1836: @@
  # chmod 400 /etc/pki/tls/certs/*.pem</code>
+===== Konfiguration =====
+==== ssl.conf ====
+Bei der Konfiguration unseres TLS-gesicherten Apache-Webservers benutzen wir nun nicht die (komplette) mitgelieferte Konfigurationsdatei //**/etc/httpd/conf.d/sssl.conf**//, sondern verlagern die zum Apache vHost, egal ob name based oder IP based, passende Konfigurationsdatei.
+Wir sichern dazu erst einmal die originale Konfigurationsdatei.
+   # cp -a /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/ssl.conf.orig
+Im ersten Schritt werden wir nun bestehende Konfigurationsdatei soweit "ausdünnen und nur den ersten Teil verwenden. Den Abschnitt **SSL Virtual Host Context** können wir nun entweder komplett löschen oder entsprechend auskommentieren.
+   # vim /etc/http/conf.d/ssl.conf
+<file bash /etc/http/conf.d/ssl.conf>#
+# When we also provide SSL we have to listen to the
+# the HTTPS port in addition.
+#
+Listen 443 https
+##
+##  SSL Global Context
+##
+##  All SSL configuration in this context applies both to
+##  the main server and all SSL-enabled virtual hosts.
+##
+#   Pass Phrase Dialog:
+#   Configure the pass phrase gathering process.
+#   The filtering dialog program (`builtin' is a internal
+#   terminal dialog) has to provide the pass phrase on stdout.
+SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
-===== Konfiguration ====
+#   Inter-Process Session Cache:
-Viele wervolle Hinweise zu den Konfigurationsparameter findet man in der Dokumentation zum [[http://httpd.apache.org/docs/current/mod/mod_ssl.html|Apache Module mod_ssl]] und [[http://httpd.apache.org/docs/current/ssl/ssl_howto.html|SSL/TLS Strong Encryption How-To]].
+#   Configure the SSL Session Cache: First the mechanism
+#   to use and second the expiring timeout (in seconds).
+SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
+SSLSessionCacheTimeout  300
-http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite
+#   Pseudo Random Number Generator (PRNG):
+#   Configure one or more sources to seed the PRNG of the
+#   SSL library. The seed data should be of good random quality.
+#   WARNING! On some platforms /dev/random blocks if not enough entropy
+#   is available. This means you then cannot use the /dev/random device
+#   because it would lead to very long connection times (as long as
+#   it requires to make more entropy available). But usually those
+#   platforms additionally provide a /dev/urandom device which doesn't
+#   block. So, if available, use this one instead. Read the mod_ssl User
+#   Manual for more details.
+SSLRandomSeed startup file:/dev/urandom  256
+SSLRandomSeed connect builtin
+#SSLRandomSeed startup file:/dev/random  512
+#SSLRandomSeed connect file:/dev/random  512
+#SSLRandomSeed connect file:/dev/urandom 512
+#
+# Use "SSLCryptoDevice" to enable any supported hardware
+# accelerators. Use "openssl engine -v" to list supported
+# engine names.  NOTE: If you enable an accelerator and the
+# server does not start, consult the error logs and ensure
+# your accelerator is functioning properly.
+#
+SSLCryptoDevice builtin
+#SSLCryptoDevice ubsec
+##
+## SSL Virtual Host Context
+##
+#<VirtualHost _default_:443>
+#
+## General setup for the virtual host, inherited from global configuration
+##DocumentRoot "/var/www/html"
+##ServerName www.example.com:443
+#
+## Use separate log files for the SSL virtual host; note that LogLevel
+## is not inherited from httpd.conf.
+#ErrorLog logs/ssl_error_log
+#TransferLog logs/ssl_access_log
+#LogLevel warn
+#
+##   SSL Engine Switch:
+##   Enable/Disable SSL for this virtual host.
+#SSLEngine on
+#
+##   SSL Protocol support:
+## List the enable protocol levels with which clients will be able to
+## connect.  Disable SSLv2 access by default:
+#SSLProtocol all -SSLv2
+#
+##   SSL Cipher Suite:
+##   List the ciphers that the client is permitted to negotiate.
+##   See the mod_ssl documentation for a complete list.
+#SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
+#
+##   Speed-optimized SSL Cipher configuration:
+##   If speed is your main concern (on busy HTTPS servers e.g.),
+##   you might want to force clients to specific, performance
+##   optimized ciphers. In this case, prepend those ciphers
+##   to the SSLCipherSuite list, and enable SSLHonorCipherOrder.
+##   Caveat: by giving precedence to RC4-SHA and AES128-SHA
+##   (as in the example below), most connections will no longer
+##   have perfect forward secrecy - if the server's key is
+##   compromised, captures of past or future traffic must be
+##   considered compromised, too.
+##SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
+##SSLHonorCipherOrder on
+#
+##   Server Certificate:
+## Point SSLCertificateFile at a PEM encoded certificate.  If
+## the certificate is encrypted, then you will be prompted for a
+## pass phrase.  Note that a kill -HUP will prompt again.  A new
+## certificate can be generated using the genkey(1) command.
+#SSLCertificateFile /etc/pki/tls/certs/localhost.crt
+#
+##   Server Private Key:
+##   If the key is not combined with the certificate, use this
+##   directive to point at the key file.  Keep in mind that if
+##   you've both a RSA and a DSA private key you can configure
+##   both in parallel (to also allow the use of DSA ciphers, etc.)
+#SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
+#
+##   Server Certificate Chain:
+##   Point SSLCertificateChainFile at a file containing the
+##   concatenation of PEM encoded CA certificates which form the
+##   certificate chain for the server certificate. Alternatively
+##   the referenced file can be the same as SSLCertificateFile
+##   when the CA certificates are directly appended to the server
+##   certificate for convinience.
+##SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
+#
+##   Certificate Authority (CA):
+##   Set the CA certificate verification path where to find CA
+##   certificates for client authentication or alternatively one
+##   huge file containing all of them (file must be PEM encoded)
+##SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
+#
+##   Client Authentication (Type):
+##   Client certificate verification type and depth.  Types are
+##   none, optional, require and optional_no_ca.  Depth is a
+##   number which specifies how deeply to verify the certificate
+##   issuer chain before deciding the certificate is not valid.
+##SSLVerifyClient require
+##SSLVerifyDepth  10
+#
+##   Access Control:
+##   With SSLRequire you can do per-directory access control based
+##   on arbitrary complex boolean expressions containing server
+##   variable checks and other lookup directives.  The syntax is a
+##   mixture between C and Perl.  See the mod_ssl documentation
+##   for more details.
+##<Location />
+##SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
+##            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
+##            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
+##            and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
+##            and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \
+##           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
+##</Location>
+#
+##   SSL Engine Options:
+##   Set various options for the SSL engine.
+##   o FakeBasicAuth:
+##     Translate the client X.509 into a Basic Authorisation.  This means that
+##     the standard Auth/DBMAuth methods can be used for access control.  The
+##     user name is the `one line' version of the client's X.509 certificate.
+##     Note that no password is obtained from the user. Every entry in the user
+##     file needs this password: `xxj31ZMTZzkVA'.
+##   o ExportCertData:
+##     This exports two additional environment variables: SSL_CLIENT_CERT and
+##     SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
+##     server (always existing) and the client (only existing when client
+##     authentication is used). This can be used to import the certificates
+##     into CGI scripts.
+##   o StdEnvVars:
+##     This exports the standard SSL/TLS related `SSL_*' environment variables.
+##     Per default this exportation is switched off for performance reasons,
+##     because the extraction step is an expensive operation and is usually
+##     useless for serving static content. So one usually enables the
+##     exportation for CGI and SSI requests only.
+##   o StrictRequire:
+##     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
+##     under a "Satisfy any" situation, i.e. when it applies access is denied
+##     and no other module can change it.
+##   o OptRenegotiate:
+##     This enables optimized SSL connection renegotiation handling when SSL
+##     directives are used in per-directory context.
+##SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
+#<Files ~ "\.(cgi|shtml|phtml|php3?)$">
+#    SSLOptions +StdEnvVars
+#</Files>
+#<Directory "/var/www/cgi-bin">
+#    SSLOptions +StdEnvVars
+#</Directory>
+#
+##   SSL Protocol Adjustments:
+##   The safe and default but still SSL/TLS standard compliant shutdown
+##   approach is that mod_ssl sends the close notify alert but doesn't wait for
+##   the close notify alert from client. When you need a different shutdown
+##   approach you can use one of the following variables:
+##   o ssl-unclean-shutdown:
+##     This forces an unclean shutdown when the connection is closed, i.e. no
+##     SSL close notify alert is send or allowed to received.  This violates
+##     the SSL/TLS standard but is needed for some brain-dead browsers. Use
+##     this when you receive I/O errors because of the standard approach where
+##     mod_ssl sends the close notify alert.
+##   o ssl-accurate-shutdown:
+##     This forces an accurate shutdown when the connection is closed, i.e. a
+##     SSL close notify alert is send and mod_ssl waits for the close notify
+##     alert of the client. This is 100% SSL/TLS standard compliant, but in
+##     practice often causes hanging connections with brain-dead browsers. Use
+##     this only for browsers where you know that their SSL implementation
+##     works correctly.
+##   Notice: Most problems of broken clients are also related to the HTTP
+##   keep-alive facility, so you usually additionally want to disable
+##   keep-alive for those clients, too. Use variable "nokeepalive" for this.
+##   Similarly, one has to force some clients to use HTTP/1.0 to workaround
+##   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
+##   "force-response-1.0" for this.
+#BrowserMatch "MSIE [2-5]" \
+#         nokeepalive ssl-unclean-shutdown \
+#         downgrade-1.0 force-response-1.0
+#
+##   Per-Server Logging:
+##   The home of a custom SSL log file. Use this when you want a
+##   compact non-error SSL logfile on a virtual host basis.
+#CustomLog logs/ssl_request_log \
+#          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
+#
+#</VirtualHost>
+</file>
+Die Hauptkonfiguration beschrängt sich demnach auf folgende sieben Zeilen:
+   # egrep -v '(^.*#|^$)' /etc/httpd/conf.d/ssl.conf
+<code bash>Listen 443 https
+SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
+SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
+SSLSessionCacheTimeout  300
+SSLRandomSeed startup file:/dev/urandom  256
+SSLRandomSeed connect builtin
+SSLCryptoDevice builtin</code>
+==== vHost.conf ====
+   # vim  /etc/httpd/conf.d/forum.conf
+<file apache /etc/httpd/conf.d/forum.conf>#
+# Django : 2015-10-30
+#          vHost hk-forum
+#
+# Variablen der Hostvariablen
+Define vhost hk-forum
+Define errors_log logs/${vhost}_error.log
+Define access_log logs/${vhost}_access.log
+Define ssl_log logs/${vhost}_ssl_request.log
+<VirtualHost 10.0.0.97:80>
+    ServerAdmin webmaster@nausch.org
+    ServerName ${vhost}.nausch.org
+    RewriteEngine on
+    RewriteCond %{HTTPS} off
+    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
+    # Welche Logdateien sollen beschrieben werden
+    SetEnvIf Remote_Addr "10\.0\.0\.20" dontlog
+    ErrorLog  ${errors_log}
+    CustomLog ${access_log} combined env=!dontlog
+</VirtualHost>
+<VirtualHost 10.0.0.97:443>
+    ServerAdmin webmaster@nausch.org
+    ServerName ${vhost}.nausch.org
+    ServerPath /
+    # Wer soll Zugriff auf die Webseite(n) bekommen?
+    #<Location />
+    #    Options +FollowSymLinks +Multiviews -Indexes
+    #    AllowOverride None
+    #    AuthType Basic
+    #    AuthName "Fuer den Zugriff auf den Webserver bitte Anmeldedaten eingeben!"
+    #    AuthBasicProvider ldap
+    #    AuthLDAPUrl ldaps://openldap.dmz.nausch.org:636/ou=People,dc=nausch,dc=org?uid
+    #    AuthLDAPBindDN cn=Technischeruser,dc=nausch,dc=org
+    #    AuthLDAPBindPassword "M52wFn0r0w95z5bn/\EU64FE!"
+    #    AuthLDAPBindAuthoritative on
+    #    Require ldap-user accessuser
+    #</Location>
+    # Welcher Inhalt soll angezeigt bzw. auf welchen Server sollen die HTTP-Requests
+    #weitergeleitet werden?
+    DocumentRoot   "/srv/www/html/${vhost}/"
+    DirectoryIndex index.php
+    <Directory /srv/www/html/${vhost}/>
+        Options none
+        AllowOverride Limit
+        Require all granted
+    </Directory>
+    <LocationMatch "/(config.inc.php|configs|scripts|tests|users|VIRTUALVACATIONS)/">
+        Require all denied
+    </LocationMatch>
+    # Welche Logdateien sollen beschrieben werden
+    SetEnvIf Remote_Addr "10\.0\.0\.20" dontlog
+    ErrorLog  ${errors_log}
+    CustomLog ${access_log} combined env=!dontlog
+    CustomLog ${ssl_log} "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
+    # Absicherung der Übertragung mit Hilfe von TLS
+    # Django : 2015-10-04 - TLS-Verschlüsselung mit Hilfe von mod_ssl
+    SSLEngine on
+    # Definition der anzubietenden Protokolle
+    SSLProtocol All -SSLv2 -SSLv3
+    # Definition der Cipher
+    SSLCipherSuite "AES256+EECDH +AEAD"
+    # Schlüsseldatei, mit der der CSR erstellt wurde
+    SSLCertificateKeyFile /etc/pki/tls/private/${vhost}.nausch.org.serverkey.pem
+    # Zertifikatsdatei , die von der CA signiert wurde
+    SSLCertificateFile /etc/pki/tls/certs/${vhost}.nausch.org.certificate.pem
+    # Zertifikatsdatei des bzw. der Intermediate-Zertifikate(s)
+    SSLCertificateChainFile /etc/pki/tls/certs/Intermediate.certificate.pem
+    # Änderung der Cipherorder der Clienets verneinen
+    SSLHonorCipherOrder on
+    # TLS 1.0 Kompremmierung deaktivieren (CRIME attacks)
+    SSLCompression off
+    # Online Certificate Status Protocol stapling zum Prüfen des
+    # Gültigkeitsstatus des Serverzertifikats.
+    SSLUseStapling      on
+    SSLStaplingResponderTimeout 5
+    SSLStaplingReturnResponderErrors off
+    # ist in der ssl.conf
+    # SSLStaplingCache        shmcb:/var/run/ocsp(128000)
+    # special stuff ###
+    # HTTP Strict Transport Security (HSTS), bei dem der Server dem Client im HTTP-Header
+    # mitteilt, dass dieser nur noch verschlüsselt mit dem Server kommunizieren soll.
+    Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
+    # This header enables the Cross-site scripting (XSS) filter built into most recent
+    # web browsers. It's usually enabled by default anyway, so the role of this header
+    # is to re-enable the filter for this particular website if it was disabled by the
+    # user. https://www.owasp.org/index.php/List_of_useful_HTTP_headers
+    Header set X-XSS-Protection "1; mode=block"
+    # when serving user-supplied content, include a X-Content-Type-Options: nosniff
+    # header along with the Content-Type: header, to disable content-type sniffing on
+    # some browsers. https://www.owasp.org/index.php/List_of_useful_HTTP_headers
+    # currently suppoorted in IE > 8
+    # http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx
+    # http://msdn.microsoft.com/en-us/library/ie/gg622941(v=vs.85).aspx
+    # 'soon' on Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=471020
+    Header set X-Content-Type-Options nosniff
+    # config to don't allow the browser to render the page inside an frame or iframe
+    # and avoid clickjacking http://en.wikipedia.org/wiki/Clickjacking
+    # if you need to allow [i]frames, you can use SAMEORIGIN or even set an uri with
+    # ALLOW-FROM uri https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options
+    header set X-Frame-Options DENY
+    # hide server header (apache and php version)
+    Header unset Server
+    # Only allow JavaScript from the same domain to be run.
+    # don't allow inline JavaScript to run.
+    Header set X-Content-Security-Policy "allow 'self';"
+    # Add Secure and HTTP only attributes to cookies
+    Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
+    # prevent Clickjacking Attack
+    #Header always append X-Frame-Options SAMEORIGIN
+    Header set Content-Security-Policy "default-src 'self';"
+</VirtualHost>
+</file>
 FIXME
@@ Zeile 2123: / Zeile 2496: @@
 https://addons.mozilla.org/de/firefox/addon/calomel-ssl-validation/
+https://mozilla.github.io/server-side-tls/ssl-config-generator/
+==== HSTS ====
+In der vHost-Definition unseres Apache-vHOST ergänzen wir folgende Zeile ''Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"''.
+   # vim /etc/httpd/conf.d/forum.conf
+<code bash>...
+# HTTP Strict Transport Security (HSTS), bei dem der Server dem Client im
+# HTTP-Header mitteilt, dass dieser nur noch verschlüsselt mit dem Server
+# kommunizieren soll.
+Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
+...</code>
+==== OCSP Stapling ====
+In der //**/etc/httpd/conf.d/ssl.conf**// folgende Konfigurationszeile nachtragen ''SSLStaplingCache "shmcb:/var/run/httpd/stapling_cache(128000)"''.
+   # vim /etc/httpd/conf.d/ssl.conf
+<code bash>...
+# Django : 2015-11-11
+# Chache-Definition für Online Certificate Status Protocol stapling
+SSLStaplingCache "shmcb:/var/run/httpd/stapling_cache(128000)"
+...</code>
+In der vHost-Definition unseres Apache-vHOST ergänzen wir folgende drei Zeilen.
+   # vim /etc/httpd/conf.d/forum.conf
+<code bash>...
+    # Online Certificate Status Protocol stapling zum Prüfen des Gültigkeitsstatus
+    # des Serverzertifikats.
+    SSLUseStapling      on
+    SSLStaplingResponderTimeout 5
+    SSLStaplingReturnResponderErrors off
+...</code>
+   $ openssl s_client -connect forum.nausch.org:443 -servername forum.nausch.org -status < /dev/null
+<code>CONNECTED(00000003)
+depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
+verify return:1
+depth=1 C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2
+verify return:1
+depth=0 OU = Domain Control Validated, CN = forum.nausch.org
+verify return:1
+OCSP response:
+======================================
+OCSP Response Data:
+    OCSP Response Status: successful (0x0)
+    Response Type: Basic OCSP Response
+    Version: 1 (0x0)
+    Responder Id: EE5EFFFE85DB26C626FBD3698410AD1D0DD3EF58
+    Produced At: Nov 29 18:16:05 2016 GMT
+    Responses:
+    Certificate ID:
+      Hash Algorithm: sha1
+      Issuer Name Hash: 84D56BF8098BD307B766D8E1EBAD6596AA6B6761
+      Issuer Key Hash: F5CDD53C0850F96A4F3AB797DA5683E669D268F7
+      Serial Number: 6922D213277B49AC169E77A9
+    Cert Status: good
+    This Update: Nov 29 18:16:05 2016 GMT
+    Next Update: Dec  3 18:16:05 2016 GMT
+...
+</code>
+Werden **__keine__** OCSP-Response Daten angezeigt, ist dies ein Hinweis, dass die OCSP_Konfiguration nnoch nicht richtig abgeschlossen wurde!
+Zum Testen kann man alternativ auch den Test bei [[https://www.ssllabs.com/ssltest/|Qualys SSL Labs]] oder [[https://observatory.mozilla.org/|Observatory by Mozilla]] nutzen.
+==== Secure Cookie mit HttpOnly ====
+In der vHost-Definition unseres Apache-vHOST ergänzen wir folgende Zeile ''Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
+''.
+   # vim /etc/httpd/conf.d/forum.conf
+<code bash>...
+# Add Secure and HTTP only attributes to cookies
+Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
+...</code>
+https://tools.geekflare.com/web-tools/http-header-analyzer
+| set-cookie:   | Forum=rtg65np1t1cvnrg7n30l8mad67; path=/; secure; \\ HttpOnly;HttpOnly;SecureDW7fa065a06cb74b536c124cfbe56ac6d3=deleted; \\ expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; secure; httponly;HttpOnly;Secure |
+**HttpOnly** und **Secure** kennzeichnen die erfolgreiche Änderung!
+==== HPKP ====
+[[https://tools.ietf.org/rfc/rfc7469.txt|RFC 7469]]
+   # openssl rsa -pubout -in /etc/pki/tls/private/forum.nausch.org.serverkey.pem \
+                 -outform der | openssl dgst -sha256 -binary | base64
+  writing RSA key
+  nMiOpb6vUnjCoWCkPkDaG4ND8SNWzFTsQf2ZfruLno0=
+pin-sha256="nMiOpb6vUnjCoWCkPkDaG4ND8SNWzFTsQf2ZfruLno0="
+   # openssl rsa -pubout -in /etc/pki/tls/private/forum.nausch.org._BACKUP_serverkey.pem \
+                 -outform der | openssl dgst -sha256 -binary | base64
+  writing RSA key
+  INhxSQ38nCS6ijaAAyo4xAhAZj9xeL3Xaak+GGiM2fo=
+Zum Löschen von outdated bzw. falschen key-hashes beim Firefox zuerst einam den Browser stoppen. Anschließend bearbeiten wir die Einträge in der Datei **SiteSecurityServiceState.txt** im profile-Pafd unserer Installation.
+   # vim ~/.mozilla/firefox/[unique-id].default/SiteSecurityServiceState.txt
+Nach dem Speichern unserer Änderungen starten wir den Browser neu und können wieder auf die zuvor blockierten Seiten zugreifen.
+===== Tests =====
+Artikel auf [[http://www.golem.de|golem]] [[http://www.golem.de/news/observatory-mozilla-bietet-sicherheitscheck-fuer-websites-1608-122923.html|Mozilla bietet Sicherheitscheck für Websites]]. \\
+[[https://observatory.mozilla.org/|Observatory by Mozilla]] \\
+[[https://www.ssllabs.com|Qualys SSl Labs SSL Server Test]] \\
+[[https://securityheaders.io|SecurityHeaders.io by Scott Helme]] \\