アカウント名:
パスワード:
自前のプライベート認証局か、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時間以上ズレてる場合は修正しない。
結果それで年月月日が誤って設定されるのであれば、サポートコスト上がる上にセキュリティ的にもまずい状態となるよね
Microsoftのバグはもっと根深いところに原因がある。想定外の原因で発生するので変な日付になるのでしょう。
時計がくるっている程度なら時計を直せば解決するし書いてある通り、時計がくるっている程度ならずれても数時間でしょ。日付がずれるってのは全く別なところから値がとられいるのでしょうね。もしくは仕様正しく理解しないまま実装した結果のバグ。
年月日の順番が逆とか凡ミスレベルかもよ。
何の根拠もないのに良くもまあ長々と語れるもんだ。
顧客のネットワークや機器が原因だと回答困難ってのは有ると思う。少なくとも原因踏査でSecure Time Seedingで日付が飛んだってなってるわけだし。
確認はしてないけど、数時間の乱数によるズレ程度なら日付や時刻は飛ばないと思う。RTC電池切れとかであまりに過去日だと前回シャットダウン日時にセットするとかその辺のお節介機能の副作用と考えた方が自然だと思う。
Secure Time Seedingって、1年間違えて日付をセットして、SSL/TLS使ったサイトが証明書エラーで見れないとか、Windows Updateが出来ないとかの対策で実装したのが裏目になってるパターンだと思われる。なので、狂う該当日付を持ってるマシンがどっかに居るのでしょう。
そもそもエラーコードで発生してるのでは？
プログラムは各種サービスの上に存在し。Windows updateの処理が始まるとサービスが停止する。動いているプログラム側ではエラーが出る。Windows homeで事故る原因。WindowsをServerで手動手動更新した場合も同様でプログラムを停止せずに行っているならエラーが出ている可能性がある。その引数が日付に混入したなら考えられないこともない。
セルフコメント。ストーリーのリンク先の情報読んだら理解した。OpenSSL系は互換性で必要な場合 [github.com]以外は、Server Helloのgmt_unix_timeにも乱数を詰め込んでくる [github.com]のね。結果、SSLのgmt_unix_timeが偶然ヨサゲな値になると採用されて狂うと。こりゃ、Windowsの当該機能を無効化するしかないねぇ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
時計が狂ってる機械が居るんでしょ？ (スコア: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)
結果それで年月月日が誤って設定されるのであれば、サポートコスト上がる上にセキュリティ的にもまずい状態となるよね
Re: (スコア:0)
Microsoftのバグはもっと根深いところに原因がある。
想定外の原因で発生するので変な日付になるのでしょう。
時計がくるっている程度なら時計を直せば解決するし
書いてある通り、時計がくるっている程度ならずれても数時間でしょ。
日付がずれるってのは全く別なところから値がとられいるのでしょうね。
もしくは仕様正しく理解しないまま実装した結果のバグ。
年月日の順番が逆とか凡ミスレベルかもよ。
Re: (スコア:0)
何の根拠もないのに良くもまあ長々と語れるもんだ。
Re: (スコア:0)
顧客のネットワークや機器が原因だと回答困難ってのは有ると思う。
少なくとも原因踏査でSecure Time Seedingで日付が飛んだってなってるわけだし。
確認はしてないけど、数時間の乱数によるズレ程度なら日付や時刻は飛ばないと思う。
RTC電池切れとかであまりに過去日だと前回シャットダウン日時にセットするとかその辺のお節介機能の副作用と考えた方が自然だと思う。
Secure Time Seedingって、1年間違えて日付をセットして、SSL/TLS使ったサイトが証明書エラーで見れないとか、Windows Updateが出来ないとかの対策で実装したのが裏目になってるパターンだと思われる。
なので、狂う該当日付を持ってるマシンがどっかに居るのでしょう。
WindowsあるあるではWindows updateが原因では？ (スコア:0)
そもそもエラーコードで発生してるのでは？
プログラムは各種サービスの上に存在し。
Windows updateの処理が始まるとサービスが停止する。
動いているプログラム側ではエラーが出る。
Windows homeで事故る原因。
WindowsをServerで手動手動更新した場合も同様で
プログラムを停止せずに行っているならエラーが出ている可能性がある。
その引数が日付に混入したなら考えられないこともない。
Re: (スコア:0)
セルフコメント。
ストーリーのリンク先の情報読んだら理解した。
OpenSSL系は互換性で必要な場合 [github.com]以外は、Server Helloのgmt_unix_timeにも乱数を詰め込んでくる [github.com]のね。
結果、SSLのgmt_unix_timeが偶然ヨサゲな値になると採用されて狂うと。
こりゃ、Windowsの当該機能を無効化するしかないねぇ。