In deze blog wil ik even stilstaan bij de resultaten van een performance test die niet overeenkwamen met de verwachtingen die wij als team hadden. Een aantal transacties gingen in responstijd omhoog en het CPU gebruik nam flink toe. Omdat het ons veel tijd heeft gekost, deel ik dit graag met jullie zodat wij performance testers hier in de toekomst kostbare tijd mee kunnen besparen!
Uiteindelijk zagen we dat bij de SSL/TLS handshake een verkeerde cipher werd gebruikt.
Daarom beschrijf ik onderstaand hoe je er achter komt welke SSL/TLS versie en cipher je moet instellen in VuGen en hoe je dit dan doet.
Wat is SSL/TLS?
SSL staat voor Secure Sockets Layer en is een encryptie-protocol die de communicatie tussen computers beveiligd. Vaak wordt de term SSL gebruikt terwijl SSL veelal is vervangen door TLS (Transport Layer Security).
Het opzetten van een verbinding met een andere computer gebeurt volgens de volgende stappen:
Uitwisselen publieke sleutels, vergelijken ondersteunde SSL/TLS versies en afspreken versleutelmechanisme (cipher).
Op basis van uitgewisselde publieke sleutels wordt een gezamenlijke sleutel (session key) bepaald m.b.v. het Diffie-Hellman-mechanisme.
De uitwisseling van data vindt nu plaats gebaseerd op de afgesproken cipher en de session key.
Waarom zorgde het gebruik van de verkeerde cipher voor hogere responstijden en CPU toename?
De ene cipher is de andere niet. In productie wordt een zogenaamde NULL-cipher gebruikt. Oftewel, het verkeer wordt niet versleuteld. In mijn performance test gebruikte LoadRunner de default cipher ECDHE-RSA. In dit geval wordt het verkeer dus wel versleuteld en dit was dan ook de oorzaak van de hogere responstijden en CPU gebruik.
Hoe kom je nu achter de juiste SSL version en cipher?
Dit is een beetje afhankelijk van de situatie. Wordt de applicatie benaderd via een browser of via een andere applicatie?
In het geval van een applicatie die benaderd wordt via de browser, kan je de openssl tool gebruiken. Deze is beschikbaar in de bin folder van je loadrunner installatie: Virtual User Generator\bin of LoadRunner\bin.
Door de applicatie te runnen, kom je in een command prompt. Hier typ je het commando:
In de output zal dan iets staan als:
Als we het nu hebben over een applicatie die benaderd wordt door een andere applicatie, moet de SSL versie en cipher op een andere manier achterhaald worden. Dit kan bijvoorbeeld door de beheerders hiernaar te vragen of door in de (productie) logging te (laten) kijken van de web server die de applicatie bedient. Op mijn opdracht wordt Apache gebruikt en daar worden SSL protocol en cipher gelogd in de access log. In de log pattern is dit gedefinieerd als %{SSL_PROTOCOL} en %{SSL_CIPHER}. Voorbeeld:
1.1.1.1 - - <datum/tijd> SUCCESS TLSv1.1 ECDHE-RSA-AES256-SHA "POST /ta/ HTTP/1.1" 200
En hoe stel je de SSL_VERSION en SSL_CIPHER nu in?
In VuGen kan je SSL version en cipher instellen via de functie web_set_sockets_option.
SSL version kan ook ingesteld worden via Runtime Settings (Internet Protocol > Preferences > General > SSL version). De cipher kan hier niet ingesteld worden.
Als ik de gegevens overneem van de voorbeelden, moeten de volgende regels toegevoegd worden aan het VuGen script:
web_set_sockets_option("SSL_VERSION", "TLS1.1");
web_set_sockets_option("SSL_CIPHER_LIST", "ECDHE-RSA-AES256-SHA");
Let wel op het volgende: de oplettende lezer heeft vast al gezien dat de waarde voor SSL_VERSION niet helemaal overeenkomt met de voorbeelden. Er staat namelijk TLS1.1 i.p.v. TLSv1.1. In de Vugen Function Reference kan je de toegestane waardes terugvinden.
De toegestane waardes voor SSL_CIPHER_LIST is niet beperkt. De waarde NULL-MD5 staat bijvoorbeeld (nog) niet in deze lijst, maar wordt wel geaccepteerd en heeft ook effect bij het runnen van het script.
Ik ben heel benieuwd of dit iets is wat jezelf ook wel eens hebt meegemaakt. Ook lees ik graag of je weleens soortgelijke uitdagingen hebt gehad. Ik hoor dus graag van je😉!