Размена кључа TLS наспрам клијентског сертификата: шта се пријављује?

Ношење јавне вредности размене кључа у руковању није исти догађај као пријава клијента. Једно успоставља криптографско стање за везу; друго каже ко је клијент и дешава се само када то сервер затражи и размена то подржи. Ако прво схватите као друго, доћи ћете до погрешних закључака о томе шта VPN скрива, а шта не. Прочитајте поруке, па одлучите коју сте од четири особине заиста приметили.

Два објекта која у снимку изгледају исто

TLS 1.3 клијент може дати материјал за размену кључа у свом првом лету без представљања икаквог сертификата. Тај је допринос јаван по дизајну, јер га сервер треба да би извео заједничку тајну. Клијентски сертификат је друга порука и шаље се тек након што га сервер затражи. Он носи идентитет који сервер затим проверава, а узајамна аутентификација је одлука сервера, а не особина коју намеће пакет шифара. Идентитет апликације је сасвим трећа ствар: образац за пријаву, bearer токен, колачић. Ништа од тога се не појављује у руковању, и све то преживљава промену мрежног пута.

Четири реда су независна. Веза може имати први и други ред, прескочити трећи и ипак носити четврти у заглављу колачића.

Одлучите шта снимљено руковање може доказати

Из самог руковања посматрач научи преговарану верзију, пакет шифара, серверски сертификат и јавне вредности размене кључа. То је довољно да се узме отисак клијентске имплементације и види којем је серверу приступљено. Оно што не даје јесте приватно стање потребно за дешифровање везе; његова тајност почива на ефемерној размени, а не на јавном делу. Не даје ни идентитет налога, којег од почетка није било у руковању.

Зато је искрен закључак узак: у овој размени није представљен ниједан клијентски сертификат. Није реч о томе да клијент није послао ништа што се може повезати, и сигурно није о томе да сесија није носила никакав идентификатор.

Читајте поруке, а не име шифре

Питајте сервер шта тражи, уместо да закључујете из пакета шифара. Руковање TLS 1.3 са захтевом за сертификат видљиво је у транскрипту, а његово одсуство једнако видљиво.

openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'

Затим поновите са конфигурисаним клијентским сертификатом и упоредите. Други пролаз треба да покаже да се сертификат шаље и прихвата; први не треба да покаже ништа, и то је конкретна разлика о којој је реч.

openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet

Ако вам треба само уобичајен случај прегледања, детаљан излаз клијента довољан је да видите верзију протокола, резултат провере и да ли је клијентски сертификат понуђен. Сервер који никада не шаље захтев за сертификат није га могао примити.

Где настављање мења одговор

Настављање TLS 1.3 користи тикете повезане с тајним стањем, па каснија веза може завршити без пуне размене сертификата. То смањује оно што посматрач види и мења оно што транскрипт доказује. Оно не ствара идентитет тамо где га није било. Настављена сесија и даље припада истој сесији апликације, а сваки колачић или токен у тој сесији остаје идентификатор који је важан.

Зато преглед приватности који стане на "нема клијентског сертификата" промашује занимљиви део. Питање је која страна држи стабилан идентификатор, а не која је порука изостала из једног руковања.

Запишите четири особине, а не једну пресуду

Запишите договор о кључу, проверу сервера, аутентификацију клијента и идентитет апликације као четири одвојена реда, с доказом за сваки. Тај списак преживљава промене верзије протокола и чини аргумент о приватности проверљивим од стране неког другог. Затим додајте шта доприноси мрежни пут. VPN мења изворну адресу коју услуга види; он не уклања пријаву, колачић или отисак уређаја које апликација већ има.

Запишите преговарану верзију везе и исход захтева за сертификат заједно, јер тај пар рецензенту треба да репродукује ваш закључак без властитог снимка.