SSL sehr langsam

[xtramen]

Hallo Leute,

habe einen vServer bei 1und1 und habe mir einen SSL Proxy installiert.
Es funktioniert alles bestens aber der Zugriff auf https Seiten läuft extreeem langsam.

Seitenaufbau bis zu 30-40 Sekunden und das bei einer reinen html Seite ohne Bilder.

Ich hab keine Ahnung was ich optimieren könnte, deshalb hoffe ich das mir einer von euch einen Tipp geben könnte.

Gruss

[daemotron]

So ganz ohne Logs ist das schwer zu sagen, aber mal ins Blaue geraten würde ich sagen, dass zu wenig Zufallsdaten zur Verfügung stehen... die meisten SSL-Implementierungen (wie z. B. OpenSSL) greifen auf vom Kernel bereitgestellt Zufallsdaten zurück. Mag angehen, dass auf dem vServer ein paar zu viele Prozesse genau dieses tun, so dass ständig alle darauf warten, dass neue Zufallsdaten nachgeliefert werden...

[dtdesign]

Erinnert mich irgendwie an diesen Thread...

Aber wie jfreund bereits erwähnte, poste bitte mal relevante Logauszüge, ein cat auf /dev/urandom könnte auch ganz hilfreich sein (um jfreunds' These zu belegen/widerlegen).

[xtramen]

Danke für eure Unterstützung!

Also ich habe nun mal cat /dev/urandom ausgeführt.

Allerding werden wirr und zufällige Zeichenkombinationen ausgegeben und das schon seit gut 10 min....

Stoppt das auch wieder? ;-)

Due Logs liefern ja keinen Fehler, welche Logs wären denn hier relevant?

Gruss

[sledge0303]

In der Regel die Logs des Webdaemons evtl. sieht man manchmal auch was in den syslogs. Ich selbst hab mal auf einer Xen VM eine javabasierende Software mit SSL Verschlüsselung installiert bzw. eingerichtet.
Die SSL Verbindung wird innerhalb von Sekunden aufgebaut ohne große Wartezeiten, auch bei erhöhter Last. Hab dabei auch festgestellt, beim Test mit einigen Browsern, der Firefox baut im Vergleich zum IE7 sowie Opera deutlich langsamer die Seiten auf...

[Roger Wilco]

ein cat auf /dev/urandom könnte auch ganz hilfreich sein (um jfreunds' These zu belegen/widerlegen).

Du meinst /dev/random. Aus /dev/urandom bekommst du immer Daten, auch wenn der Entropy-Pool leer ist. ;)

Allerding werden wirr und zufällige Zeichenkombinationen ausgegeben und das schon seit gut 10 min....

Stoppt das auch wieder? ;-)

Nein. Einfach mit ^C abbrechen.

Wenn du Spass daran hast, kannst du die Performance von OpenSSL auch einfach mal mit `openssl speed` testen. Es wäre durchaus denkbar, dass der V-Server schlicht zu schwach ist oder einer der Nachbarn nutzt die CPU etwas intensiver...

[xtramen]

Gesagt getan :-)

Ein openssl speed ergab:

Code: Select all

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md2               1654.44k     3558.74k     5005.73k     5522.19k     5745.25k
mdc2              4653.02k     5263.00k     5460.60k     5393.74k     5497.26k
md4              16169.37k    57475.31k   169935.85k   329539.37k   455911.75k
md5              14613.06k    51345.50k   151296.51k   285623.44k   389998.48k
hmac(md5)        22200.60k    70910.43k   186350.88k   312530.82k   399004.65k
sha1             14092.12k    46260.68k   123750.23k   213138.48k   269080.25k
rmd160           11943.95k    35814.95k    81694.65k   121567.11k   141113.98k
rc4             174568.76k   196691.16k   200752.30k   204323.26k   203700.55k
des cbc          54211.88k    57375.92k    58150.48k    58043.96k    58845.87k
des ede3         19279.88k    19932.76k    19939.01k    19972.75k    19854.82k
idea cbc             0.00         0.00         0.00         0.00         0.00
rc2 cbc          20253.36k    21096.36k    21003.79k    21187.31k    21179.85k
rc5-32/12 cbc        0.00         0.00         0.00         0.00         0.00
blowfish cbc     88006.87k    93983.02k    94106.10k    95925.06k    96085.11k
cast cbc         41324.89k    44758.68k    45066.00k    45026.84k    45853.35k
aes-128 cbc      60590.66k    62755.98k    64278.53k    64146.48k    63752.08k
aes-192 cbc      53553.50k    54567.50k    54502.91k    55578.79k    55645.92k
aes-256 cbc      46578.85k    48293.38k    49247.57k    49069.94k    48796.29k
                  sign    verify    sign/s verify/s
rsa  512 bits   0.0005s   0.0000s   1847.0  21455.0
rsa 1024 bits   0.0022s   0.0001s    448.7   8647.5
rsa 2048 bits   0.0122s   0.0004s     81.9   2818.1
rsa 4096 bits   0.0777s   0.0012s     12.9    824.9
                  sign    verify    sign/s verify/s
dsa  512 bits   0.0004s   0.0005s   2604.6   2181.3
dsa 1024 bits   0.0010s   0.0013s    973.4    788.5
dsa 2048 bits   0.0033s   0.0040s    307.5    252.3

und ein cat /dev/random ergab:

Code: Select all

o
 DNù[ùþÒ,gb6"³ÊK¶,S|Pq;4úÛȵ)@=²ÉÖ)Ót¶(úö,ø­¿¬½ÙHÖ,ÂÃ0Ïx²ZaXâ
¦.ÈØhò&C¯
äEm5ÜG¤ýÕîض7¿Ñ]N` Ö
Z+|ãøîÏ;Ç|      ÔV
BÁ[b(¼ÜcÇ«t»xxxüé¡ò«I5rd9Ñ`¨Dci(Ú¸IO%mè¸,뢧3ìkôðµ;!q²8MEÉ0ú9;îÈËÝÄâªØ&B7Ð[næøå¯ñIhrïÀÞ¡¶,mk©±×¾èH
p¼.iÜâ]÷°`«ÜB+Æw
                Rî6xÀàý
Æö³r½Y¬b/§ÌQämA¢TÈüÕæì7¸4_±ïöÃ’´o.´l±kXÊpÃÏ£ñý~.Í:á°¶ö5è6P-ÚÞl¨£åÉY¬ÁvïÁû^el0,)×VdÙêþU$úääoÛz;µÈ4Ã|¡ 12:õÿԦưHÄ)¾ÆH¿{(ÀÿKxWìl7ÛvmÑ.Hù`ͲB¸ÕÌÓ±%¾
b               Ý3ìØPM¯ мã[°Òg3ªÄø»JÃ…oæϽ¨ÐÖÍ
  éÁ7Êoìoçú¿@o[²õ                              1ÕWé®aT6

Leider kann ich aus diesen Daten rein gar nichts deuten, Ihr?

Gruss

[Roger Wilco]

Leider kann ich aus diesen Daten rein gar nichts deuten, Ihr?

Lediglich dass der Entropy-Pool nicht leer war, was aber auch in /proc/sys/kernel/random/entropy_avail steht. Ansonsten war das unnütz. ;)

[xtramen]

Hmm.
Dann gibts da wirklich keine Möglichkeit da irgendwas zu optimieren?

Gruss

[pzystorm]

Vllt ein Entropy Gathering Daemon.

Außerdem ist es bewiesen und steht sogar im Apache Manual, dass /dev/*random langsamer ist, als die im Apache eingebaute Random-Funktion, die nämlich nur auf Timestamps und Prozessübersichten basiert.

Außerdem solltest du in Erwägung ziehen, nur die Verfahren und Protokolle zu benutzen, die die CPU am geringsten beansprucht:
SSLProtocol SSLv2
SSLCipherSuite "EXP-RC4-MD5"

Oder gleich einen SSH-Tunnel zwischenschalten und in den Apaches ganz auf SSL verzichten. Ich vermute, dass das geschwindigkeitstechnisch das beste sein wird. Zumal der Tunnel nur 1x aufgebaut wird... und nur 1x Primzahlen berechnet werden.

Beim Apache-SSL wird alle naselang was berechnet. Keep-Alive scheint bei SSL-Proxies nicht so wirklich zu klappen.

Außerdem schafft das Fasterfox Plugin für den Firefox noch ein bisschen Speed. Der tweakt an den Beschränkungen für gleichzeitige SSL-Verbindungen rum.

[xtramen]

Ok Danke Dir aber das ist mir leider doch ein bissle zu hoch ;-(.

Wäre Dir schon dankbar wenn Du mir kurz noch sagen könntest wo ich das Protokoll ändere.
habe es in der /etc/Apache2/ssl-global.conf probiert. Ist das korrekt?

Gruss