Vor zwei Jah­ren hatte ich mich pro­jekt­be­dingt mit die­sem Thema be­schäf­ti­gen dür­fen – umso neu­gie­ri­ger war ich auf den Mit­schnitt die­ses Vor­tags. tl;dr: An­schau-Emp­feh­lung für alle, die ir­gend­wie etwas mit SSL und Per­for­mance-The­men zu tun haben (ins­be­son­de­re Web­mas­ter), eine sehr schö­ne Zu­sam­men­fas­sung der ver­schie­de­nen As­pek­te.

Is TLS Fast Yet?

Da­zu­ge­hö­ri­ge Res­sour­cen: Die Fo­li­en sowie die Web­sei­te „Is TLS Fast Yet?“, auf der noch­mals alle Fak­ten zu­sam­men­ge­tra­gen sind (ein­schlie­ß­lich der Mög­lich­keit zum Mit­ma­chen und Er­gän­zen in Form von Pull Re­quests auf git­hub).

Kurz zu­sam­men­ge­fa­ßt die Punk­te des Talks:

• Auf mo­der­nen Stan­dard-CPUs ist die sym­me­tri­sche Kryp­to vom Auf­wand her ver­nach­läs­sig­bar, le­dig­lich der Hand­shake zu Be­ginn ist „spür­bar“. Bei ge­eig­ne­ter Kon­fi­gu­ra­ti­on gibt es aber kei­nen Grund, auf spe­zi­el­le Kryp­to-Hard­ware zu­rück­zu­grei­fen.
• Erste Op­ti­mie­rung: Ses­si­on Re­su­me (am bes­ten mit­tels Cli­ent-sei­ti­gen Ses­si­on Ti­ckets, um den ser­ver­sei­ti­gen Spei­cher­be­darf pro Ses­si­on zu re­du­zie­ren).
• Ab­schal­ten von TLS-Com­pres­si­on: Ab­ge­se­hen von An­griffs­mög­lich­kei­ten wie z.B. CRIME ver­grö­ßert TLS den Spei­cher­be­darf pro Ver­bin­dung er­heb­lich. Sinn­vol­ler ist es, den hö­her­lie­gen­den Pro­to­kol­len (z.B. http) die Kom­res­si­on zu über­las­sen.
• Kon­fi­gu­ra­ti­on der Key Ro­tai­ton über­prü­fen. Ist lei­der per De­fault bei vie­len Ser­vern nicht kor­rekt kon­fi­gu­riert, und ohne Key Ro­ta­ti­on keine Per­fect For­ward Se­crecy.
• Ich er­gän­ze an die­ser Stel­le: Durch Wahl ge­eig­ne­ter Ver­fah­ren aus der SSL Suite er­reicht man neben Per­fect For­ward Se­crecy auch unter Um­stän­den klei­ne­re Zer­ti­fi­ka­te, was sich in Da­ten­men­ge und Über­tra­gungs­dau­er be­merk­bar macht.
• Das für das Über­prü­fen der Zer­ti­fi­kats­gül­tig­keit ver­wen­de­te OCSP ist ein Quell ste­ter Schmer­zen. Wenn mög­lich: OCSP Stap­ling ver­wen­den und die Re­vo­ca­ti­on Info durch den Ser­ver mit aus­lie­fern.
• Die Größe des TCP Con­ges­ti­on Win­dow kann per­for­man­ce­tech­nisch bei­ßen, wenn die Zer­ti­fi­akt­sket­te so groß ist, daß zwi­schen­rein auf ein ACK ge­war­tet wer­den muß.
• Per­fect For­ward Se­crecy zu­sam­men mit ALPN er­mög­li­chen False Starts (hier wird die erste Pay­load mit letz­tem Hand­shake-Block mit­ge­sen­det).

Bei un­ter­schied­li­chen Web­ser­vern (und dort auch in­ner­halb von Ver­sio­nen) gibt es wohl er­heb­li­che Un­ter­schie­de, es lohnt sich, die Ta­bel­len zum Vor­trag an­zu­se­hen – und am Ende selbst zu tes­ten und nach­zu­mes­sen.

Ein sau­ber op­ti­mier­tes OpenS­SL schafft den er­streb­ten „One Round­trip Hand­shake“ und be­nö­tigt pro Con­nec­tion ca. 100 kb RAM. Googles in­tern ver­wen­det SSL-Bi­blio­thek re­du­ziert den Spei­cher­be­darf bis auf 10 kb, viel­leicht dür­fen wir hof­fen, diese Op­ti­mie­run­gen in Zu­kunft zu­min­dest auch in Bo­ringS­SL, Gool­ges OpenS­SL-Fork, wie­der­zu­fin­den.