Споделяне на ключ по TLS срещу клиентски сертификат: кое влиза?
Разграничете съгласуването на ключ от удостоверяването на клиента и идентичността на приложението и прочетете съобщенията при ръкостискането, които показват кое от тях връзката действително е използвала.
Преносът на публична стойност за обмен на ключове при ръкостискане не е същото събитие като влизане на клиент. Едното установява криптографско състояние за връзката; другото посочва кой е клиентът и се случва само когато сървърът го поиска и обменът го поддържа. Да приемете първото за второ води до грешни изводи за това какво VPN скрива и какво не. Прочетете съобщенията и след това решете кое от четири свойства действително сте наблюдавали.
Два обекта, които изглеждат еднакво в запис
Клиент TLS 1.3 може да предостави материал за обмен на ключове в първия си полет, без да представя какъвто и да е сертификат. Този принос е публичен по замисъл, защото сървърът се нуждае от него, за да изведе споделената тайна. Клиентският сертификат е друго съобщение и се изпраща само след като сървърът поиска такъв. Той носи идентичност, която сървърът после проверява, а взаимното удостоверяване е решение на сървъра, а не свойство, което наборът от шифри налага. Идентичността на приложението е съвсем трето нещо: форма за вход, bearer токен, бисквитка. Нищо от това не се появява при ръкостискането и всичко то преживява смяна на мрежовия път.
| Object in play | What it establishes |
|---|---|
| Key-exchange share | Cryptographic state for this connection |
| Server certificate | Which server the client reached |
| Client certificate | Client authentication, when requested |
| Application session | Account identity inside the application |
Четирите реда са независими. Връзката може да има първи и втори ред, да пропусне трети и въпреки това да носи четвърти в заглавка на бисквитка.
Решете какво може да докаже записаното ръкостискане
Само от ръкостискането наблюдателят научава договорената версия, набора от шифри, сертификата на сървъра и публичните стойности за обмен на ключове. Това е достатъчно да се снеме отпечатък на клиентска реализация и да се види кой сървър е бил потърсен. Това, което не дава, е частното състояние, нужно за дешифриране на връзката; неговата тайна почива на ефимерния обмен, а не на публичния дял. Не дава и идентичност на акаунт, каквато изобщо не е имало в ръкостискането.
Затова честният извод е тесен: в този обмен не е представен клиентски сертификат. Работата не е, че клиентът не е изпратил нищо свързваемо, и със сигурност не е, че сесията не е носила идентификатор.
Четете съобщенията, а не името на шифъра
Питайте сървъра какво иска, вместо да правите извод от набора от шифри. Ръкостискане 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 променя адреса на източника, който услугата вижда; той не премахва вход, бисквитка или отпечатък на устройство, които приложението вече държи.
Запишете договорената версия на връзката и резултата от заявката за сертификат заедно, защото точно тази двойка е нужна на рецензента, за да възпроизведе извода ви без собствен запис.