[PHP] Sicherheit des Traffic

[Scar]

ich wollte hier keine grundsatzdiskussion auslösen..
nur man darf online/it-geschichten eben nicht auf den einzelnen betrachten, sondern auf die gesamte menge der nutzer und abhängigkeiten. das waren also nur nen paar denkansätze..

es hat schon einen grund, wieso viele der großen webserver 8-16 xeon cpu's und mehr haben und trotzdem noch im cluster aufgestellt werden müssen

die verlagerung von session-informationen in die db dürfte übrigens nicht wirklich den großen vorteil bringen, denn auch die db muss daten persistieren und damit schreiben. wenn man transaction-basierte dbms nutzt, wäre dann der schreib-aufwand sogar noch um ein vielfaches höher.

 

[ice-breaker]

die verlagerung von session-informationen in die db dürfte übrigens nicht wirklich den großen vorteil bringen, denn auch die db muss daten persistieren und damit schreiben. wenn man transaction-basierte dbms nutzt, wäre dann der schreib-aufwand sogar noch um ein vielfaches höher.

auf Platten müssen die User immer bei jedem Request beim gleichen Server landen, bei Datenbanken kann man mit Replikation die Daten auf die Server wieder verteilen.
Zudem könnte man Memory-Tabellen nutzen, Sessions werden sehr oft in der Db gehalten.

 

[Talion]

Man sollte dann schon <form action="https://..."> machen, dann geht das auch.

Dann hast du streng genommen aber wieder eine verschlüsselte Verbindung, bevor man eingeloggt ist. Ich hatte dich ursprünglich so verstanden, dass erst eingeloggte User Verschlüsselungs nutzen können sollen, um bspw. DoS-Angriffe gegen TLS zu erschweren.

 

[shenziro]

Dann hast du streng genommen aber wieder eine verschlüsselte Verbindung, bevor man eingeloggt ist. Ich hatte dich ursprünglich so verstanden, dass erst eingeloggte User Verschlüsselungs nutzen können sollen, um bspw. DoS-Angriffe gegen TLS zu erschweren.

Wenn du DoS wirklich erschwehren willst, schaltest am besten gleich den Server ab.. Denn damit hat mehr oder weniger TLS nichts zu tun!

Aber wenn man z.B. folgendes Formular über eine unverschlüsselte Verbindung verschickt, kann man trotzdem sagen: "Ich will die Antwort aber verschlüsselt!"

<form action="https://.../">
<input type="text" name="login">
<input type="password" name="pw">
</form>

Oder willst du jetzt sagen, dass der Login dann unverschlüsselt übermittelt wird? Also ich weiß nicht, aber seitdem ich denken kann, wird ein Formular an die URL im Parameter "action" geschickt. ^^

Wenn es aber jetzt darum geht, dass die verschlüsselte Verbindung ja besteht und der Nutzer auch ein falsches Passwort eingeben kann und somit einmal TLS hatte ohne eingeloggt zu sein: Tjo, so ist das Leben. Du kannst ja schlecht vorher prüfen, ob der Login erfolgreich sein wird, um dann die Verbindung zu verschlüsseln und den Nutzer einzuloggen...

 

[No5251]

SSL kostenlos https://www.cacert.org

 

[Talion]

Wenn du DoS wirklich erschwehren willst, schaltest am besten gleich den Server ab.. Denn damit hat mehr oder weniger TLS nichts zu tun!

Das stimmt nur halb. Überall wo Kryptographie (oder andere rechenintensive Operationen) eingesetzt wird, bietet man einem Angreifer zusätzliche Möglichkeiten, effektive DoS-Angriffe durchzuführen. Insofern hätte es schon einen gewissen Sinn, nicht jedem dahergelaufenen Besucher TLS anzubieten. Nur ist das halt im allgemeinen Fall nicht sinnvoll durchführbar.

<form action="https://.../">
<input type="text" name="login">
<input type="password" name="pw">
</form>

Oder willst du jetzt sagen, dass der Login dann unverschlüsselt übermittelt wird?

Nein will ich nicht. Das hatte ich nur für so selbstverständlich gehalten, dass ich in deiner ersten Aussage einen anderen Sinn vermutet hatte. Und schon im letzten Beitrag habe ich geschrieben, dass ich dich offenbar missverstanden hatte, daher ist diese ganze Diskussion hier gerade ziemlich sinnlos.

 

[No5251]

Überall wo Kryptographie (oder andere rechenintensive Operationen) eingesetzt wird, bietet man einem Angreifer zusätzliche Möglichkeiten, effektive DoS-Angriffe durchzuführen.

Da schaffen die Apache-Module "mod_evasive" und "mod_security" Abhilfe.

"mod_evasive" liefert bei zu vielen Anfragen nur noch 404er und es kann ein
Skript angestoßen werden, das die IP in die Blacklist der Firewall einträgt.
"mod_security" kann schon bevor Apache eine Anfrage bekommt, die Daten
nach verdächtigen Mustern durchsuchen und verwerfen. Ist auch eine feine
Sache gegen altbekannte SQL-Injection-Versuche.