Varför en svit har många namn

En enda chiffersvit kan skrivas på minst tre sätt, och skillnaderna får alla att snubbla som jämför en serverkonfiguration med en paketdump eller en skannerrapport. Sviten som kallar TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 är samma som OpenSSL kallar ECDHE-RSA-AES128-GCM-SHA256. De beskriver identiska byte på tråden, nämligen kodpunkten 0xC02F.

Kodpunkten är det enda protokollet faktiskt använder. Namnen är bekvämligheter för konfigurationsfiler, dokumentation och människor, och varje verktygsekosystem lät sin egen konvention växa fram.

De tre konventionerna

Code point: 0xC02F
IANA:       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
OpenSSL:    ECDHE-RSA-AES128-GCM-SHA256
GnuTLS:     TLS_ECDHE_RSA_AES_128_GCM_SHA256

IANA-namnet är registerstandarden. Det börjar alltid med TLS_, skiljer varje token med ett understreck och använder ordet WITH för att dela nyckelutbytet och autentiseringen från chiffret och MAC:en.

OpenSSL-namnet släpper prefixet TLS_, använder bindestreck i stället för understreck, tar bort WITH och skriver chiffret och nyckellängden som ett token (AES128 i stället för AES_128). För statiska -sviter släpper OpenSSL även det överflödiga nyckelutbytes-token, så TLS_RSA_WITH_AES_128_CBC_SHA blir helt enkelt AES128-SHA. TLS 1.3 är undantaget: där antog OpenSSL IANA-namnen oförändrade, så TLS_AES_128_GCM_SHA256 skrivs likadant i båda.

GnuTLS-namnet behåller prefixet TLS_ och understrecken men utelämnar, liksom OpenSSL, WITH. Det är det minst sedda av de tre.

Det är just denna missmatchning som får folk att tro att två system är oense när de har konfigurerat samma svit. En avkodare som accepterar vilket som helst av namnen, plus den råa kodpunkten, tar bort gissandet genom att visa dem alla på en gång.

Att läsa en kodpunkt

En chiffersvits kodpunkt är två byte, skriven på flera sätt som alla betyder samma tal:

0x1301      0x13,0x01      13 01      1301

Den första byten grupperar besläktade sviter: blocket 0x00xx rymmer de ursprungliga TLS 1.0- och 1.1-sviterna, 0xC0xx rymmer sviterna på elliptiska kurvor från RFC 5289 med flera, 0xCCxx rymmer ChaCha20-Poly1305-sviterna, och 0x13xx rymmer TLS 1.3-sviterna. Att se 0xC0 eller 0xCC i början är en snabb vink om att du tittar på en modern - eller ChaCha20-svit.

Vad Recommended-kolumnen betyder

IANA-registret har en Recommended-kolumn med tre värden, och de är lätta att läsa fel.

Y betyder att sviten har gått igenom :s konsensusprocess och rekommenderas för allmänt bruk vid registreringstillfället. N betyder inte att sviten är trasig; det betyder att den inte gått igenom den processen, har begränsad tillämplighet eller är avsedd för en specifik nisch. CCM_8-sviterna är märkta N av just detta skäl: den avkortade taggen är en medveten kompromiss, inte ett fel.

D är det starka. Det betyder att sviten är avrådd och inte bör, eller inte får, användas beroende på situationen. Hela familjer har flyttats till D allteftersom IETF fasar ut dem, däribland de statiska RSA-sviterna och, på senare tid, DHE-sviterna över ändlig kropp. En svit kan vara kryptografiskt sund och ändå märkas D av ekosystemskäl, och därför visar avkodaren IANA-märkningen bredvid sin egen säkerhetsbedömning i stället för att smälta samman de två till ett enda omdöme. De besvarar olika frågor: är konstruktionen sund, och vill standardiseringsprocessen fortfarande att du använder den?

Att foga ihop allt

För att identifiera en okänd svit klistrar du in formen du har – ett IANA-namn, ett OpenSSL-namn eller en kodpunkt – i avkodaren. Den löser sviten mot en inbäddad kopia av IANA-registret, visar de andra namnen, bryter ner sviten i sina delar och parar en regelbaserad säkerhetsbedömning med den officiella IANA-rekommendationen. Följdartiklarna förklarar delarna själva: den allmänna anatomin, valet mellan och , forward secrecy och vad TLS 1.3 ändrade.