「サーバー証明書」を含む日記

はてなキーワード: サーバー証明書とは

2023-10-21

■acmeは別に 卑猥な単語ではない

acmeは英語で絶頂、極致、全盛期って意味で、例えばthe acme of beauty(美の極致)ってな感じで使われるんだが、日本だともっぱら女性のオーガズムの意味で使われるから困る。

ITのサーバー証明書関連や普通の英文で出てくるとこれアクメって読んでいいんじゃろか？と困惑する。人前で発音しなければならないとき、アクメって言っちまっていいのか？と。

(サーバー証明書関連だとアクミーって読んだらいいらしいね。恥ずかしがらず堂々と言おう。)

AV・風俗業界？はなぜこの言葉を日本に持ち込んで使用したのか。

Permalink | 記事への反応(0) | 10:25

2023-01-07

■chatGPTに勉強教えてもらってる

SSLのサーバー証明書はリバースプロキシサーバを使っていればそこにインストールする必要があるようですが。理由がよくわかりません。教えてください。

SSLのサーバー証明書をインストールする場所は、そのサーバー証明書を使用するWeb サーバやアプリケーションサーバ、メールサーバなどにインストールする必要があります。

リバースプロキシサーバを使用している場合には、クライアントからのリクエストを受け取り、それを代理として、サーバへ転送するサーバであるため、そこにはサーバー証明書をインストールする必要はありません。

ただし、リバースプロキシサーバを介して、クライアントからのリクエストを処理するWeb サーバやアプリケーションサーバ、メールサーバなどには、サーバー証明書が必要になることがあります。これは、そのサーバが信頼されることを示す証明書であり、そのサーバがSSL 通信を行うために必要です。

また、リバースプロキシサーバを使用することで、クライアントからのリクエストを受け取るサーバを変更することができます。そのため、リバースプロキシサーバを使用している場合には、サーバー証明書をインストールする必要があるサーバを変更することもできます。　

Permalink | 記事への反応(0) | 08:40

2021-09-18

■東武ストアのサーバー証明書が死んだようだな

最近某漫画の公式サイトもやらかしてたけど、資本金一億越えの大手私鉄系スーパーでもこんな雑な運用なのか。

https://www.tobustore.co.jp/

NET::ERR_CERT_DATE_INVALID
Subject: www.tobustore.co.jp
Issuer: GlobalSign GCC R3 DV TLS CA 2020
Expires on: 2021/09/18
Current date: 2021/09/18

Permalink | 記事への反応(2) | 18:24

2014-02-27

■Apple's SSL/TLS bug (22 Feb 2014)の意訳

例のAppleのSSL/TLSのバグの件、日本語情報がなかったので意訳しました。

Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。

Apple's SSL/TLS bug (22 Feb 2014)
https://www.imperialviolet.org/2014/02/22/applebug.html
(Hi Adam Langley, Than you for your blog! We really appreciate you.)

-----

昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。
それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。

その答えは既にハッカーニュースのトップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。
そして現在、俺たちはその誤った情報を正すステージに来ているんだ。

ほらここに、Appleのbugがあるんだ。：

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
 OSStatus        err;
 ...

 if ((err = SSLHashSHA1.update(&amp;amp;hashCtx, &amp;amp;serverRandom)) != 0)
  goto fail;
 if ((err = SSLHashSHA1.update(&amp;amp;hashCtx, &amp;amp;signedParams)) != 0)
  goto fail;
  goto fail;
 if ((err = SSLHashSHA1.final(&amp;amp;hashCtx, &amp;amp;hashOut)) != 0)
  goto fail;
 ...

fail:
 SSLFreeBuffer(&amp;amp;signedHashes);
 SSLFreeBuffer(&amp;amp;hashCtx);
 return err;
}(Quoted from Apple's published source code.)

(訳者注：(Quoted from Apple's published source code)→sslKeyExchange.c)

2行のgotoがあるだろ。
2行目のgotoは、見て分かる通り常に発動する。
変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。
それって成功したのと同じなんだよね！

この署名検証処理は(訳者注：SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージの署名を検証するものだ。
このServerKeyExchangeでは、"the ephemeral key"（通信のための一時的な鍵）を交換するためのDHE や ECDHE という暗号スイートが使われる。
そのサーバーは言うんだ。
「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね！」

今、もし"the ephemeral key"と証明書の関係が破たんしているならば、すべては無意味なんだ。
これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った（つまり適当にその辺で作った）鍵を使ったり、そもそもハンドシェイクに署名しなかったりってことができるってことなんだよ！

そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵の秘密鍵を持っているってことの証明が、何もないんだ。

これはSecureTransport(というライブラリ)に入っていて、以下に影響する。
・iOS 7.0.6より前(俺は7.0.4で確認した)
・OS X 10.9.2より前(10.9.1で確認した)
(訳者注：つまりiOS 7.0.6、OS X 10.9.2で解決した)

これはSecureTransportを使っているすべてに影響するけど、ChromeとFirefoxはそうじゃない。
ChromeとFirefoxはSSL/TLSのためにNSSを使っている。
でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね)


超特急でテストサイトを作ってみたよ。https://www.imperialviolet.org:1266
ポート番号に気を付けてね。(テストサイトはCVE番号になってるよ)
443は通常通りに動いているからね。

ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキーで署名しているんだ。
君がもしポート1266のHTTPSサイトにアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:)


それってつまり、証明書チェーンは正しいってことで、そしてハンドシェイクと証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。

またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。
攻撃者は、この暗号スイートを使うサーバーを自分で建てるようになるだろう。

また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。
でも攻撃者は使うプロトコルをある程度選ぶことができるから、安心できないよ。
(訳者注：サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。)
でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。
同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。
(2つのうち、1つ目のほうがだいぶ好ましい。)

俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。
(更新：このバグはOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。)

こんなような微妙なバグって、悪夢だ。
俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。


ここに、今回の問題を明らかにするコードがある。：

extern int f();

int g() {
 int ret = 1;

 goto out;
 ret = f();

out:
 return ret;
}

もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeのGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。
本当にビックリだよ！！！

ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。
(ピーター・ネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない！)

if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。
でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。

テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。
TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。
俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも)

コードレビューはこの種類のバグについて効果的でありえる。
ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。
Appleのコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。
でも、誰もがそんなにいい仲間を持てるわけじゃないよね。


最後に。昨日、Appleが証明書のホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、
それは OS X のコマンドラインでcurlを使うと、IPじゃない証明書でもIPでHTTPSにつながっちゃうってだけだったよ。変だけど。
Safariはこの問題には関係なかったよ。