Абмен ключамі 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 змяняе адрас крыніцы, які бачыць сэрвіс; ён не выдаляе ўваход, кукі або адбітак прылады, якія праграма ўжо мае.
Запішыце ўзгодненую версію злучэння і вынік запыту сертыфіката разам, бо менавіта гэтая пара патрэбная рэцэнзенту, каб аднавіць вашу выснову без уласнага запісу.