Då kan ni förstå hur uppspelt jag blev av att IBM har testat prestanda i WS-Security -- Java Web Services: The high cost of (WS-)Security! Här kommer en sammanfattning.
WS-* för säkerhets skull
WS-* innehåller allehanda tekniker för att säkra dina web services. WS-Security för kryptering och signering av XML, WS-Policy för att förhandla fram säkerhetsnivå mellan klient och server och WS-SecureConversation för att säkra en serie meddelanden mellan klient och server.
Dyra operationer
WS-Security löser de traditionella problemen med meddelandesäkerhet:
- Confidentiality -- hemlighålla meddelandet mha kryptering
- Integrity -- försäkra sig om att meddelandet inte manipulerats eller skadats
- Authenticity -- försäkra sig om att meddelandet kommer från en betrodd avsändare
Men det är dyra operationer.
XML-kryptering handlar om att generera symmetrisk nyckel, kryptera payload, kryptera den symmetriska nyckeln med mottagarens publika nyckel och sen lägga till krypterad nyckel, eget certifikat och information om vilka algoritmer som används i XML:en. Det tar tid och XML:en växer rejält.
XML-signering handlar om att kanonikalisera payload:en (typ "ta bort all white space och alla radbrytningar"), beräkna en checksumma, kryptera den med sin privata nyckel och sen lägga till krypterad checksumma, eget certifikat och information om vilka algoritmer som används i XML:en. Gissa vad? Det tar tid och XML:en växer rejält.
Men hur dyrt är det? Det har IBM tagit reda på.
Testkonfiguration
Testsystemet var en 64-bitars Linux, Java 1.6 från Sun, Tomcat 6, Axis 2 och Rampart 1.5, en säkerhetsmodul för Axis 2. Man körde anropen internt på en maskin för att inte introducera nätverksstrul i mätningarna. 1000 anrop med små svar (blå staplar), 1000 anrop med stora svar (röda/orangea staplar). Mätningarna gjordes med följande konfigurationer:
- plain: Ingen säkerhet
- ssl: HTTPS till servern (envägs)
- username: WS-Security:s UsernameToken i klartext i anropen
- sign: WS-Security-signering av meddelande och headers, med tidsstämpel
- encr: WS-Security-kryptering av meddelande
- signencr: Kombinationen av sign och encr ovan
Signering + kryptering ger 2000 % sämre prestanda
Det visar sig att envägs-SSL har ganska god prestanda, särskilt vid större meddelanden (handskakningen blir mindre andel). Men WS-Security suger enormt med energi -- 2000 % sämre prestanda med både signering och kryptering.
Orsakerna är flera. Först och främst så kräver signeringen att man kanonikaliserar XML:en för att white space inte ska påverka signaturen. Det är en transform som lättast utförs med en DOM vilken i sin tur tar tid att generera. Resten av prestandan går åt till att beräkna checksumma och till symmetrisk kryptering -- båda CPU-krävande operationer.
WS-SecureConversation presterar bättre
WS-SecureConversation är i princip säkerhet för en hel web service-session. Istället för att generera symmetriska krypteringsnycklar och kryptera dem med asymmetrisk nyckel för varje meddelande så kommer server och klient överens om en sessionsnyckel och kör på den. Det minskar både storleken på meddelanden (inget cert och mindre nyckelinfo att skicka) och minskar arbetet med kryptering och dekryptering (bara symmteriskt). Därför presterar WS-SecureConversation bättre än vanlig WS-Security-kryptering:
Hur mycket större blev XML:en?
Hur mycket större blir då din XML av att signera och/eller kryptera den? Ja, ett anropsmeddelande kan blir 12 gånger så stort.
Slutsatser
- Om dina klienter kopplar direkt till slutmottagaren (inga servrar emellan) och du inte behöver kunna bevisa meddelandets äkthet i efterhand så duger SSL.
- Om du har mellanliggande servrar så bör du köra WS-Security. SSL:en termineras ju vid första servern och du har inget tätt skydd även om du sätter upp nya SSL-koppel bakåt. Hemliga data riskerar att hamna i loggar och cache:ar utanför din kontroll. Observera att det kan vara data som du inte ens vill ha i dina system -- kreditkortsnummer med efterföljande PCI-DSS-certifiering till exempel.
- Om du vill kunna bevisa ett meddelandes äkthet (authenticity) så bör du köra WS-Security. Med SSL skulle du få lov att "spela in" hela nätverkssessionen för att kunna bevisa något.
(Det finns möjlighet att skaffa hårdvarustöd för WS-Security, t ex Vordel XML Gateway men det är en annan historia, med en annan prislapp.)
Inga kommentarer:
Skicka en kommentar