keine Session möglich, obwohl diese angelgt wird

Lord_Icon

Lord_Icon

Member
Hi,

ich hhabe das Problem, dass auf meinen Server keine Session mehr akzeptiert wird. Vor ein paar Tagen habe ich versucht die Bewertung einer SSL-Domain anzuheben (ssl-labs). Diese Änderung habe ich auch schon wieder rückgängig gemacht. (/etc/apache2/mods-available/ssl.conf)

Bei der Seite wo die Probleme auftreten ist es aber eh ohne verschlüsselung.
Sollte vermutlich nicht an SSL liegen.
Andere Websiten können/dürfen Session angelegt werden. Somit muß es ja was mit der vHost zu tun haben.

Aber is die 100'%tig identisch mit anderen vhost. (von den Pfaden mal abgesehen)

aber ihr dürft das natürlich gern selbst prüfen:
Code: 
 <Directory "/var/www/htdocs/web1/html">
  AllowOverride All
  Options +FollowSymLinks +SymLinksIfOwnerMatch +Includes

  <IfModule mod_access.c>
   Allow from all
  </IfModule>
 </Directory>

<VirtualHost 179.220.115.17:80>
 ServerName domain.de
 ServerAlias www.domain.de
 ServerAlias *.pro.domain.de
 DocumentRoot "/var/www/htdocs/web1/html"
 ScriptAlias /cgi-bin/ /var/www/htdocs/web1/html/cgi-bin/
 php_admin_flag safe_mode Off
 php_admin_value open_basedir /var/www/htdocs/web1
 php_admin_value session.save_path /var/www/htdocs/web1/temp
 php_admin_value upload_tmp_dir /var/www/htdocs/web1/temp
 php_admin_value safe_mode_exec_dir /var/www/htdocs/web1/temp
 php_admin_value mail.add_x_header 1
 php_admin_flag allow_url_include On
 php_admin_flag allow_url_fopen On
 php_admin_value max_execution_time 10000
</VirtualHost>

Code: 
ls -lach /var/www/htdocs/web1/temp
root@server:/var/www/htdocs/web1# ls -lach /var/www/htdocs/web1/temp
insgesamt 4,6M
drwxrwxrwx 2 web1    www-data 4,5M Nov 10 09:42 .
drwxr-xr-x 5 root     root     4,0K Mär 23  2016 ..
-rw------- 1 www-data www-data  171 Nov 10 09:31 sess_051mcpnhh81mvv2nq3pjdcv9h7
-rw------- 1 www-data www-data   16 Nov 10 09:36 sess_18eaipiuugmam6anecnuq2s9e5
-rw------- 1 www-data www-data  117 Nov 10 09:42 sess_1gk7tbjvmram3osn7nqnrcvl73
-rw------- 1 www-data www-data   46 Nov 10 09:34 sess_2cf9n5ev7jj4fcvead6h0rd272
-rw------- 1 www-data www-data  116 Nov 10 09:32 sess_2rlcs3rr3f3m8tf5htukk7q3p7
-rw------- 1 www-data www-data    0 Nov 10 09:33 sess_4b0qhbrfdjn2du2ojkcm37rmg2
-rw------- 1 www-data www-data  171 Nov 10 09:30 sess_4bq5j9ie2r85evipe7n77iiif5
-rw------- 1 www-data www-data  171 Nov 10 09:31 sess_4eraubtbel0c3rgajpn746s445
-rw------- 1 www-data www-data   46 Nov 10 09:33 sess_4q7s6f7imv99spdeo26ltqbi41

Code: 
root@sever:/var/www/htdocs/web1# ls -lach /var/www/htdocs/web1/
insgesamt 4,5M
drwxr-xr-x  5 root  root     4,0K Mär 23  2016 .
drwxr-xr-x 59 root  root     4,0K Sep 14 09:52 ..
drwxrwxrwx  5 web1 www-data 4,0K Nov 10 09:19 backup
drwxrwxrwx 15 web1 www-data 4,0K Nov 10 09:19 html
drwxrwxrwx  2 web1 www-data 4,5M Nov 10 09:46 temp

Schreibrechte sind da... Sessions werden auch angelegt.
Immer wenn ich auf F5 drücke wird eine neue angelegt.
Nur darauf zurückgreifen kann er nicht.

Weiß einer Rat, wo ich was verbaut habe ?
 
Last edited by a moderator:
Nachtrag.

ich hab jetzt 2 phpinfo's mal vergleichen...
Ein paar wenige Abweichungen konnte ich finden. Lt. Web aber nicht wirklich für mein Problem zuständig... oder wie seht Ihr das
Code: 
HTTP_ACCEPT_ENCODING 	
gzip, deflate, br    => br fehlt bei der Problemseite
HTTP_COOKIE 	PHPSESSID=5hcru249s9fk82uhgv6teepki0  => eintrag fehlt ganz



HTTP Headers Information
Accept-Encoding 	gzip, deflate  => wieder das br fehlend
Cookie 	PHPSESSID=5hcru249s9fk82uhgv6teepki0  => fehlt wieder komplett
Cache-Control 	max-age=0 => eintrag fehlt ganz


ZUSÄTZLICH bei der Problemdomain hab ich folgendes gefunden. Dieser Eintrag hatte die andere Domain wo Session funktionieren nicht
Set-Cookie 	PHPSESSID=gtlj329u74et03g9sbhot1lsn4; path=/var/www/htdocs/web1/temp
 
GELÖST:

Es war doch die /etc/apache2/mods-available/ssl.conf.
Erstaunlich, dass die auch bei http-Seiten greift.

Erst dachte ich, ich hätte alles rückgängig gemacht (da ich die Änderungen entsprechend kenntlich gemacht habe).
Die Datei aus n Backup hat dann die Lösung gebracht

ALT: Fehlerhaft:
Code: 
SSLProtocol TLSv1.2

        SSLHonorCipherOrder on
        SSLCompression off
Header always set X-Frame-Options SAMEORIGIN 
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure 
Header always set X-Content-Type-Options nosniff 
         SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH 
        <IfModule mod_headers.c>
                Header always set Strict-Transport-Security "max-age=31556926"
        </IfModule>

Die aus n Backup und somit funktional:
Code: 
SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS


Vlt. stolpert ja einer mal über das gleiche Problem
 
Configs werden immer in den Kontext des Import-Statements importieret. Bei mod-enabled ist das der globale Kontext. Entsprechend wirken sich Direktiven, die darin nicht innerhalb von zB einem Virtualhost stehen, global aus.
Wenn du im der Config Header setzt, die nicht im SSL-Virtualhost stehen, dann setzt du die global. Das ist das erwartete Verhalten.
 
korrekt. War mir schon bewust.. und war auch so gewünscht.
Sonst hätte ich es in die vHost gepackt.

Habe mehrere SSL Seiten und deshalb war der Globale Weg für mich der passende. Was soweit auch ganz gut klappt. Zumindest konnte ich das Rating um 2 Stufen anheben. Und bei SSL Seiten geht dies Session ja.

Was mir halt immer noch nicht ganz klar ist, wasum eine Config, die bei https greifen sollte auch http "angreift"... und dann abweichend von SSL derartige Probleme verursacht.

Ich hacke es mal ab als... klingonisch... is aber so :eek:
 
Lord_Icon said:
Was mir halt immer noch nicht ganz klar ist, wasum eine Config, die bei https greifen sollte auch http "angreift"... und dann abweichend von SSL derartige Probleme verursacht.
Click to expand...

Deine Konfigurationsänderungen greifen wie oben schon geschrieben global und somit auch die folgende:
Code: 
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Und macht nach meinem Verständnis nichts anderes, als das Secure-Flag beim Cookie zu setzen. Das Secure-Flag teilt dem Browser mit, dass der Cookie nur über sichere Verbindungen wieder an den Server geschickt werden soll. Chrome und Firefox gehen (jeweils seit Version 52) wohl sogar soweit, dass sollte Cookies bei einer unverschlüsselten Verbindung gar nicht erst angenommen und im Browser gespeichert werden. Die Browser machen letztendlich nur das, was du ihnen gesagt hast.
Solange du auch noch unverschlüsselte Webseiten betreibst, muss die Header-Zeile bei den vHosts eingetragen werden, die bereits verschlüsselt laufen.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top