第52話で、イトはurgent mailのbuttonを押さなかった。
messageが用意したlink / reply / phoneを閉じ、pre-existing official bookmarkからknown URLを選び直した。
official urgent eventは0だった。
今度は、そのknown URLへ通信を始める。
client target cardにはstage.picoroute.test。
server certificate cardにはstage-mirror.picoroute.test。
key agreement lampはgreenだが、identity match lampはdarkのままだ。
「暗号化の準備ができているなら、このまま進んでも中身は読まれないよね」
イトはcertificate warningのoverride leverへ手を掛けた。
live controlを開始するまで、あと五十秒。
TLSは、鍵だけでなく相手の名前も結ぶ
ピコはoverride leverへ触れず、client target cardとserver certificate cardの間にtransparent comparatorを置いた。
イト
鍵を作れそうなのに、名前が違うだけで止めるの？
ピコ
誰との鍵かを確かめずにapplication dataを送らないためだよ
イト
certificateに書かれた名前へ、client側を合わせればいい？
ピコ
それではserverが示した名前を正解にしてしまう。known targetを先に保とう
この話のHTTPS client、server、certificate、trust store、TLS 1.3 handshake、recordsは、外のInternetから切り離した学習fixtureだ。
hostnameはreserved .test、certificate / keyは説明用labelで、real private keyやpublic endpointを使わない。
TLS 1.2以下、cipher suite選定、key schedule数学、0-RTT、session resumption、mutual TLS、corporate interceptionは再現しない。
HTTPSは、target authorityとのHTTPを守る
RFC 9110のhttps URI Schemeは、https URIのauthorityがhostとoptional portを含み、そのtargetとのHTTP communicationをTLSでsecureにする枠組みを定義する。
ここでsecureとは、identified authorityを代表するserverのauthenticationと、client / server間HTTP communicationのconfidentiality / integrity protectionを含む。
pathやqueryは、そのorigin内のtarget resourceを選ぶ。
まず「どのURLへ行くか」があり、そのtargetに対してTLSを使う。
TLSが、userの意図したbrand名やbusiness purposeを後から選んでくれるわけではない。
第52話でknown URLを選び直したのは、このreference sideをmessage任せにしないためだった。
reference identityは、certificateを見てから作らない
clientには、接続前から期待するservice identityがある。
今回のreference identifierは、known URLから作ったstage.picoroute.testだ。
serverはTLS negotiation中、certificateでpresented identifierを示す。
最初のrouteが示したのはstage-mirror.picoroute.testだった。
RFC 9525 Service Identity in TLSは、clientがreference identifierをserverのpresented identifierとは独立に作り、certificate内のpresented identifierとmatchする手順を定める。
serverが示した名前へreferenceをその場で書き換えれば、comparisonの意味がなくなる。
一文字似ているかではなく、protocolが定めるidentifier type / matching ruleで照合する。
certificateは、名前以外もvalidationする
name matchだけでcertificate validation全部が終わるわけではない。
clientは、certificate chainがconfigured trust anchorへつながるか。
validity period等のpolicy checkを通るか。
serverがcorresponding private keyをcontrolしていることをCertificateVerify等で示すか。
handshake transcriptがFinishedまで一貫するか。
このfixtureはtrust chain、time、name、proof-of-key-controlをseparate lampsで観察する。
revocation / certificate transparency / browser vendor policy詳細は扱わない。
「certificateが一枚ある」だけをpass条件にしない。
TLS 1.3 handshakeは、application dataの前にある
RFC 8446 TLS 1.3のfull handshakeでは、client / serverがparametersとkey sharesを交換し、server authentication側でCertificate、CertificateVerify、Finished等を使う。
handshakeが完了すると、record layerでapplication dataをauthenticated encryptionによりprotectするkeying materialが得られる。
この話ではmessage byte順やcryptographic equationを再現しない。
見る順序は三段だけだ。
target identityを持つ。
handshakeでcertificate / transcript / keysを検証する。
完了後にHTTP application dataを送る。
certificate mismatchを残したまま、login requestだけ先へ送らない。
confidentialityとintegrityは別の役割
protected TLS recordは、network途中からapplication plaintextを直接読み取りにくくする。
これがconfidentialityの入口だ。
同時にauthenticated encryptionは、recordが途中で変更されたことを受信側が検出できるようにする。
これがintegrity / authenticity protectionの入口だ。
ただしendpointへ到着し、applicationが復号したdataは、そのendpointで利用できる。
phishing site自身へsecretを送れば、network途中で暗号化されてもdestination applicationには届く。
TLSはendpointのsecurity、site contentの正しさ、data利用目的、malware不在を一括保証しない。
イトの前に、三つの選択肢が開く
live controlまで、あと二十五秒。
A name mismatchをoverrideし、暗号化lampだけで進む
key agreementは進むかもしれない。
しかしknown referenceとpresented identityが一致しないrouteへapplication dataを渡す。
B client referenceをcertificateのpresented nameへ書き換える
lampは揃う。
でもserverの提示を基準に期待値を変え、known URLを保てない。
C reference identityを保ち、mismatch routeを終了してmatching serviceへ接続する
warning overrideは使わない。
known target cardをcomparatorに残す。
fixture routerのknown mappingを再確認し、stage.picoroute.testをpresentするserverへnew handshakeを作る。
ピコはoverride leverにもrouter mappingにも触れなかった。
「暗号化できる相手じゃなく、選んだ名前と一致する相手へ送る」
イトはCを選んだ。
override leverへclosed coverを戻し、known reference cardをleft holderへ残したまま、mismatch certificate routeを自分でterminateし、matching certificate routeへnew ClientHello cardを置いた。
mismatch routeには、application dataを送らない
first traceはname mismatch routeだ。
client referenceはstage.picoroute.test。
presented identifierはstage-mirror.picoroute.test。
comparatorはno matchを返す。
connectionはbad-certificate gateでterminateした。
HTTP request body sentは0。
second traceはmatching routeだ。
presented identifier、trust path、validity、CertificateVerify、Finishedをfixture policyで検証する。
handshake complete lampがgreenになった。
その後で初めて、イトはHTTP control requestをprotected recordへ入れた。
serverはrecordをauthenticate / decryptし、accepted application cardを返した。
modified recordは、本文へ届かない
イトは別のfixture recordをnetwork midpointで一bitだけ変更した。
受信側のrecord authenticationは失敗した。
modified application bodyとしてcontrol serviceへ渡さない。
untouched protected recordはaccepted。
modified recordはrejected。
これでworkbenchには三つのobservable resultが残った。
name mismatch routeはapplication data 0。
matching routeはhandshake complete後にrequest accepted。
modified recordはapplicationへdelivery 0。
live control signalがofficial stageへ届いた。
certificate warningを、原因不明のまま消さない
identity mismatch以外にも、certificate validity、trust path、client clock、network / managed environment等でwarningが出る場合がある。
一つの原因へ決め打ちしない。
consumer向けunknown siteなら、credentialやpaymentを入れずknown routeへ戻る。
managed workplaceなら、organizationのsupport / network policyで確認する。
developer fixtureなら、hostname / certificate / trust configurationを直す。
「warning pageの先へ進めた」を修復結果にしない。
browser productごとのindicator形状やadvanced override UIも、永続するsecurity guaranteeとして一般化しない。
TLSを疑うときは、target・handshake・recordを分ける
workbenchには四つの証拠が残った。
known URL由来のreference identifier。
server certificateのpresented identifierとvalidation lamps。
Finished後にだけ開くapplication-data gate。
untouched accept / modified rejectのrecord pair。
HTTPS / TLSを鍵markだけで判断せず、clientが選んだtarget identityとcertificateのpresented identityがmatchし、certificate / handshake validationを完了してからapplication dataを送る。handshake後のrecordsはconfidentiality / integrity付きで守る。TLSはvalidated originとの通信を守るが、site content、business intent、secretを渡すべき相手かまで自動保証しない。
「鍵は通路を閉じるだけじゃない。選んだ名前と通路を結んでいた」
イトはmismatch certificateをaccepted trayへ移さず、known referenceとmatching certificateのpairだけをcurrent tunnelへ残した。
tunnelの奥に、plaintext card、ciphertext card、key holderが並ぶ机が見える。
同じdataは、keyによってどう形を変えるのだろう。
次回：読めない形は、何を守る？
イトはplaintext cardをそのままnetwork railへ置かず、encryption machineのinput holderへ差した。
「読めなくすることと、元へ戻せることはどう両立する？」
ピコはkey holderを照らしたが、machineは動かさなかった。
次回、ピコルート第54話。
イトは、文字を適当に混ぜて暗号化にしなかった｜keyは何を変える？