Le Forum Non Officiel de la DEDIBOX
Vous n'êtes pas identifié.
J'ai un openssl compilé pour utiliser le "engine padlock", j'ai compilé un apache avec mod_ssl à coté :
1) est-il logique / concevable / possible d'utiliser le padlock pour s'occuper de la crypto des flux SSL servis par Apache ?
2) comment le faire ? comment s'assurer de l'utilisation du padlock ? y-a-t-il des restrictions d'usage ? (longueur des clés, algo, etc.)
Merci ;-)
Dernière modification par frogfries (2006-05-24 14:09:35)
Hors ligne
non je ne pense pas que ça marche "tout seul".
Si j'ai bien compris, cette crypto hardware est limitée au seul algo AES pour des clés de 128 bits (il faudrait donc en tenir compte lors de l'achat de certificats SSL (?))
quand on voit qu'une petite option sur la ligne de commande d'openssl fait que la crypto hardware est utilisée ou pas :
http://forums.viaarena.com/messageview. … erthread=y
crypto soft :
openssl speed aes-128-cbc -engine padlock
crypto hard :
openssl speed -evp aes-128-cbc -engine padlock
j'imagine que pour que apache utilise le padlock, c'est assez pointu niveau config..
sinon, peut etre quelquechose à faire du coté de la directive de mod_ssl d'apache
SSLCryptoDevice ?
( http://httpd.apache.org/docs/2.2/mod/mo … yptodevice )
Hors ligne
Résultat des courses avec https padlocked ;-)
Je n'ai pas trop cherché à comprendre pourquoi la directive apache 2.2 SSLCryptoDevice ne voulait pas de mon padlock, j'ai légèrement modifié mod_ssl pour le forcer à ne pas oublier le padlock (ajout d'un ENGINE_load_padlock() après ENGINE_load_builtin_engines() dans mod_ssl.c)
C'est évidement pas la bonne façon de le faire mais bon.... bref !
wget en local d'un fichier de 66 Mo :
en http : 138 Mo/s
en https builtin (pas de padlock) : 4,2 Mo/s
en https padlock : 6,6 Mo/s
(soit 50% de mieux, *quand même* ;-)
le tout avec un certificat AES 256 bits.
Hors ligne