NICT、http／httpsによる時刻配信を段階的に廃止することを決定。NTPに一元化へ 26
ストーリー by nagazou
毎月1時間ずつ伸びていくのだろうか 部門より
毎月1時間ずつ伸びていくのだろうか 部門より
標準電波を発射して日本標準時を通報している情報通信研究機構（NICT）は、NTPを利用した時刻配信を一元化し、これまで提供してきた「http／https」を利用した時刻配信は停止するとする方針を発表した。今後はNTPに一元化を行うとし、http／httpsに関しては段階的に時限停止を行うことでユーザへの周知をするとしている（NICT）。
以前からhttp／httpsを利用した時刻配信は、http／httpsを利用した時刻配信により一時的に停止を行うことがあると通知されていた、。今回の判断は不安定な運用になる可能性の高いhttp／httpsにより時刻配信を廃止し、NTPを利用した時刻配信へ一元化することにより安定化を図るとしている。現在http／httpsによる時刻配信を利用している事業者や個人はNTPの活用をするよう求めている。
停止は段階的に行われるとしており、7月に関しては
以前からhttp／httpsを利用した時刻配信は、http／httpsを利用した時刻配信により一時的に停止を行うことがあると通知されていた、。今回の判断は不安定な運用になる可能性の高いhttp／httpsにより時刻配信を廃止し、NTPを利用した時刻配信へ一元化することにより安定化を図るとしている。現在http／httpsによる時刻配信を利用している事業者や個人はNTPの活用をするよう求めている。
停止は段階的に行われるとしており、7月に関しては
- 7月20日(月)~24日(金) 12:00~13:00 1時間停止
- 7月27日(月)~31日(金) 12:00~13:00 1時間停止
というスケジュールとなっている。なお停止時間は徐々に長時間化していくとしている（時限停止のお知らせ）。
あるAnonymous Coward 曰く、
ネットワークを利用した時刻配信におけるNTPへの一元化について
～ http/httpsを利用した時刻配信の停止に向けた取組み～
https://jjy.nict.go.jp/httphttps-index.html
NICTのhttp/httpsによる時刻供給、アクセス過多の場合にサービスを一時停止するとアナウンス
https://it.srad.jp/story/20/02/03/1255225/
以前からhttp／httpsを利用した時刻配信は、http／httpsを利用した時刻配信により (スコア:1)
わけがわからない。
「アクセス過多により」の間違いだろうか。
Re: (スコア:0)
http／httpsを利用した時刻配信のページ（http://www.nict.go.jp/JST/http.html）に
「アクセス過多が発生した場合には予告なくサービスの停止を行います。」と書いてあるので
舌足らずではありますが、間違ってはいないと思います。
Re: (スコア:0)
後半はページタイトルなのか。そりゃ知らなかったら意味が通じない。
NTPは脆弱で、なりすましが容易 (スコア:1)
NTPは、HTTPSのように安全ではなく、なりすましが容易にできてしまいます。
例えば、出社・退社の時刻を管理するタイムカードシステムがあって、そのコンピュータがNTPで時刻同期していたとします。
同じLAN内からは、ARPスプーフィングというテクニックでNTPサーバを詐称することが簡単にできてしまい、
偽のNTPサーバと同期させる → 出社登録する → ARPスプーフィングを止めてもとのNTPサーバと同期させる
とすることにより、勤務時間を不正に改竄することができます。
ログからバレて処分を受けるかもしれないのにタイムカード改竄なんて有り得ないって？
だったら、気に入らない同僚を冤罪に陥れるために、同僚の登録前後で改竄するなんてことも有り得ます。
DNS等も over HTTPS にしようというのが時代の流れなのに、今更脆弱なNTPに戻すなんてナンセンスです。
Re:NTPは脆弱で、なりすましが容易 (スコア:4, 参考になる)
OpenNTPDでは、あなたの指摘したような問題を解決するための仕組みが組込まれています。
設定ファイルntpd.conf (抜粋)
OpenNTPDは設定ファイル中のconstraint行で指定されたウェブサーバと通信を行い、証明書の検証で使われるタイムスタンプを取得します。
このタイムスタンプは精密なものである必要はありませんが、「検証された時刻」となっています。
次に、servers行で指定されたサーバとNTPプロトコルで通信を行い、時刻の同期を取ろうとします。
この時、NTPサーバが返してきたタイムスタンプがTLS通信で取得されたタイムスタンプと大きく異っている場合、そのNTPサーバは時刻の参照元としては採用されません。
いつの時代の話をしてるんだ (スコア:0)
って言いに来たんだけどどこにぶら下げるのが良いだろうか。
Re:NTPは脆弱で、なりすましが容易 (スコア:3, 興味深い)
NTPが危険って話は2015年ぐらいで大体終わっています。
NTPの欠陥は2014年に沢山指摘されていて、それを受け2015年に NTP から NTPsec というプロジェクトがフォークしています。
https://www.ntpsec.org/ [ntpsec.org]
関連するRFCとしては、2014年にでたrfc7384が該当していて、ntpsec はこれを実装したものになっています。
https://tools.ietf.org/html/rfc7384 [ietf.org]
ntpsec はその後2016年に初版がリリースされ、今では多くのOSで標準パッケージになっています。
ですから、なりすまし対策が必要なら、 ntpsec を使えばそれだけで解決です。少なくとも5年間の実績があります。
いまさら over HTTPS なんて言い出すほうが、よっぽどナンセンスです。
Re: (スコア:0)
ntpsecって、どれくらい普及してるんですか。
Re:NTPは脆弱で、なりすましが容易 (スコア:1)
Re: (スコア:0)
一応あることにはあるけど、
・対応しているタイムカード専用機は少ない
・対応していてもMD5のみ
というのが現状
Re: (スコア:0)
httpsに対応しているタイムカード専用機のほうが少ない気がします。
Re: (スコア:0)
何でslewモード使ってないの？
Re: (スコア:0)
NTPはそんなに頻繁に時刻調整するものではないし、ログからバレて処分されるのはタイムカード改ざんに対してではなくARPスプーフィングによるNTPサーバーへの攻撃に対してでしょう。
Re: (スコア:0)
ARPスプーフィングを誰がやったかなんて特定は事実上不可能ですよ
特に鞄の中に入れたWi-Fi端末(無論MACアドレスは詐称)からやったら防犯カメラにも何も映らないしね
Re: (スコア:0)
勝手端末を社内LANにつなげられる時点で脆弱。
さらにその設定ではARPスプーフィングを止めることができない。
Re: (スコア:0)
arp が問題なんだから、IPv6 にして NTP 使えばいい。
NTP2036年問題に今から対策を!! (スコア:0)
NTPなど、1900年1月1日からの積算秒数で時間を表現するシステムもあり、符号なし32ビットの値が2036年2月7日6時28分15秒 (UTC) を超えるとオーバーフローすることによって問題が発生する（→2036年問題）。
Re: (スコア:0)
2036年ごろには
「NICTへのNTPアクセスのうち1.3%は2036年問題非対応のバージョン」
みたいな記事が立つけど、実際にはほとんどが疎通確認やクライアント側で対応済みで別に問題が起きない…
みたいな落ちが目に見えるな。
古いルーターが無駄に時間が狂ってるけど別に問題なく動作したままとかそういうのはありそう。
Re: (スコア:0)
ウィキペディアの続き
SNTPv4を定めたRFC 4330には、最上位ビットが0の場合は時刻が2036年から2104年の間であるとみなして、2036年2月7日6時28分16秒 (UTC) を起点として計算することで2036年問題を回避する方法が書かれている。
最上位ビットの意味を読み替えるよう定期的にRFCを更新していけば安心！
時刻合わせページ用のAPIは維持される？ (スコア:0)
お知らせによると
以下にはこの一元化及び時限的な停止による影響はありません
✔ 当機構のhttp/httpsによる時刻配信を利用していないほとんどのスマートフォン・PC等のアプリケーション
✔ ご使用の端末と標準時の時刻差を表示する以下のページ時刻合わせページ（下図）
https://www.nict.go.jp/JST/JST5.html [nict.go.jp]
とのことですが、二つ目の時刻合わせページは[ランダムな16進数].nict.go.jp/cgi-bin/jsonから時刻を取得しているみたいなので、この（隠し？）APIは維持されるということなんですかね？
YOU、NTPS、書いちゃいなよ (スコア:0)
時代が変わったのだからバージョン上げてセキュアになってもいいんじゃない？。
https://tools.ietf.org/html/rfc1305 [ietf.org] にコメント出してもいいのよ。知らんけど。
＃アレなんでアレでよろしく（軽いなあー
Re: (スコア:0)
NTPS(NTP over SSL) で行くか NoH(ntp-over-https) で行くか。問題はそこからだ。
何でもHTTPに載せる風潮 (スコア:0)
決して美しい実装ではなかったので、原点回帰って意味では望ましい傾向だと思う。
コネクション複数張るとか時代遅れなプロトコルはともかく、単にFWを抜けられないからって理由でHTTPに載せてるものは本来の形に戻すべき。
あと企業のFWも無意味なアウトバウンド方向の制限をやめるべき。どっちにしろ突破される。
鶏と卵 (スコア:0)
HTTPSで時刻同期するためにはwebサーバの証明書を検証する必要があって、
証明書を検証するには現在時刻とNot Before/Not Afterを比較する必要があって、
比較するためには現在時刻が正しく設定されていないといけない。
NTP 的 (スコア:0)
これ、NTP 的だなぁ。期間を長めにとって宣言する、で良い気がする。
以下余談。NTP って上りと下りの速度が同じ事が前提って聞いた気がするが、どうなのかな
Re: (スコア:0)
速度と言っても帯域幅じゃなくてレイテンシの方だと思うが、
レイテンシが大幅に偏ってるケースが一体どれほどあるか、
偏っててもそれをどうやって検出するというのか、
検出できて補正できてもそこにどの程度の効果があるのか。
まぁ理屈の上では帯域幅違えば同時に送り始めても帯域幅広いほうが先に宛先やらパケット末尾やらを読んで中継できるけど、ホップ数のほうが影響大きいし、
レイテンシが大幅に偏る為には行きと帰りで遅延の全然違う経路を通らなないと厳しいだろうし、
検出するには一々トレースルート掛けなきゃだし、それも当てにならん上に双方向分必要だし、
そんだけ頑張って何ミリ秒正確になるのか。パソコンとか大抵の機器じゃ早々にそれ以上に狂ってしまう予感。
多分ほぼ意味がない。