アカウント名:
パスワード:
自前のプライベート認証局か、IDS/IPSか、iSCSIとかのSANか、UPSなのか知らないが、時計が狂ってる奴が居るのでは?
これって、NTPをSSLでラップしたようなものなのかな?>リモートサーバーと行うSSLハンドシェイクこの「リモートサーバ」ってどこが用意するもの?Microsoft?
どこかのサイトに繋ぐとき、SSLハンドシェイク内に現れるServerUnixTimeというフィールドと、OCSPに問い合わせて得られた有効期限情報をそれぞれ使うとのこと。
いずれも正しいことを保証する仕組みではないし、意図的に乱数などの値を入れて返す実装もあるが、ネット上を見てたらだいたい合ってるみたいだし、ええんちゃう?みたいな仕組みらしい。
> 意図的に乱数などの値を入れて返す実装
これが原因なのでは。その実装が悪いわけではなさそうだけど
いや、そんな保証されていない情報をシステム時刻に使っちゃうMSがマヌケってことでFA?# ネットは悪意に溢れていると考えていないMSって純情 !!!
いやでも内部時間がミリ秒単位で知られると困るからずらすという話で、年単位ずらすことはないんじゃないの?下手すると証明書期限切れみたいな話になるし。
"ServerUnixTime" と呼ばれているのは、おそらくServer Hello内に現れる"GMT Unix Time"のフィールドかと思いますが、これはそもそも乱数の種(シード)として使うことを想定したもので、毎回異なる値でさえあれば十分なものであり、現にTLS1.3では廃止されて [nic.ad.jp]います。
なのでミリ秒単位どころか100年単位でずらしても本来の仕様上は問題ないはずのものなので、それを設計の想定を越えて流用してしまったのが問題の根本と思われます。
SSL/TLSのプロトコル上正確な時刻をやり取りする必要があるのでそれを流用するというアイデアで、特定の時刻合わせ目的のサーバーを立てる必要はない。福岡大学のサーバーに決め打ちで接続とかしない限り、文字通り「どこでもいい」。
> SSL/TLSのプロトコル上正確な時刻をやり取りする必要があるそれは正確な現在時刻がわからないと、とっくに有効期限の切れた証明書を、今も有効と勘違いさせられてしまうし、あるいは現在有効な証明書をまだ有効になっていないと勘違いしてしまう可能性もある(なのでSSLのエラー画面にはシステム時刻を確認しろと書いてある)。
なのに、どこの馬の骨ともしれぬ「リモートサーバー」が言ってきた時刻を信じ込むって正気の実装とは思えないのですが?それとも、NTPと同じで、あらかじめ正確な時刻を教えてくれると信頼するサーバーを設定しておくという話でしょうか?それなら別にNTPで良くないですか?なんかこの機能の利点あるんですか?
時計の設定で年月日を間違えて設定するようなユーザーからの、インターネットが見れない(実際は証明書エラー)のサポートコストを削れます。
※NTPは15もしくは48時間以上ズレてる場合は修正しない。
結果それで年月月日が誤って設定されるのであれば、サポートコスト上がる上にセキュリティ的にもまずい状態となるよね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
時計が狂ってる機械が居るんでしょ? (スコア:0)
自前のプライベート認証局か、IDS/IPSか、iSCSIとかのSANか、UPSなのか知らないが、時計が狂ってる奴が居るのでは?
Re:時計が狂ってる機械が居るんでしょ? (スコア:0)
これって、NTPをSSLでラップしたようなものなのかな?
>リモートサーバーと行うSSLハンドシェイク
この「リモートサーバ」ってどこが用意するもの?
Microsoft?
Re:時計が狂ってる機械が居るんでしょ? (スコア:3, 参考になる)
どこかのサイトに繋ぐとき、SSLハンドシェイク内に現れるServerUnixTimeというフィールドと、
OCSPに問い合わせて得られた有効期限情報をそれぞれ使うとのこと。
いずれも正しいことを保証する仕組みではないし、意図的に乱数などの値を入れて返す実装もあるが、
ネット上を見てたらだいたい合ってるみたいだし、ええんちゃう?みたいな仕組みらしい。
Re: (スコア:0)
> 意図的に乱数などの値を入れて返す実装
これが原因なのでは。その実装が悪いわけではなさそうだけど
Re: (スコア:0)
いや、そんな保証されていない情報をシステム時刻に使っちゃうMSがマヌケ
ってことでFA?
# ネットは悪意に溢れていると考えていないMSって純情 !!!
Re: (スコア:0)
いやでも内部時間がミリ秒単位で知られると困るからずらすという話で、年単位ずらすことはないんじゃないの?
下手すると証明書期限切れみたいな話になるし。
Re: (スコア:0)
"ServerUnixTime" と呼ばれているのは、おそらくServer Hello内に現れる"GMT Unix Time"のフィールドかと思いますが、これはそもそも乱数の種(シード)として使うことを想定したもので、毎回異なる値でさえあれば十分なものであり、現にTLS1.3では廃止されて [nic.ad.jp]います。
なのでミリ秒単位どころか100年単位でずらしても本来の仕様上は問題ないはずのものなので、それを設計の想定を越えて流用してしまったのが問題の根本と思われます。
Re:時計が狂ってる機械が居るんでしょ? (スコア:1)
SSL/TLSのプロトコル上正確な時刻をやり取りする必要があるのでそれを流用するというアイデアで、特定の時刻合わせ目的のサーバーを立てる必要はない。福岡大学のサーバーに決め打ちで接続とかしない限り、文字通り「どこでもいい」。
Re: (スコア:0)
> SSL/TLSのプロトコル上正確な時刻をやり取りする必要がある
それは正確な現在時刻がわからないと、とっくに有効期限の切れた証明書を、今も有効と勘違いさせられてしまうし、
あるいは現在有効な証明書をまだ有効になっていないと勘違いしてしまう可能性もある(なのでSSLのエラー画面にはシステム時刻を確認しろと書いてある)。
なのに、どこの馬の骨ともしれぬ「リモートサーバー」が言ってきた時刻を信じ込むって正気の実装とは思えないのですが?
それとも、NTPと同じで、あらかじめ正確な時刻を教えてくれると信頼するサーバーを設定しておくという話でしょうか?
それなら別にNTPで良くないですか?なんかこの機能の利点あるんですか?
Re:時計が狂ってる機械が居るんでしょ? (スコア:1)
時計の設定で年月日を間違えて設定するようなユーザーからの、
インターネットが見れない(実際は証明書エラー)のサポートコストを削れます。
※NTPは15もしくは48時間以上ズレてる場合は修正しない。
Re: (スコア:0)
結果それで年月月日が誤って設定されるのであれば、サポートコスト上がる上にセキュリティ的にもまずい状態となるよね