パスワードを忘れた? アカウント作成
14244776 story
インターネット

NICT、http/httpsによる時刻配信を段階的に廃止することを決定。NTPに一元化へ 26

ストーリー by nagazou
毎月1時間ずつ伸びていくのだろうか 部門より
標準電波を発射して日本標準時を通報している情報通信研究機構(NICT)は、NTPを利用した時刻配信を一元化し、これまで提供してきた「http/https」を利用した時刻配信は停止するとする方針を発表した。今後はNTPに一元化を行うとし、http/httpsに関しては段階的に時限停止を行うことでユーザへの周知をするとしている(NICT)。

以前から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/

  • わけがわからない。
    「アクセス過多により」の間違いだろうか。

    ここに返信
    • by Anonymous Coward

      http/httpsを利用した時刻配信のページ(http://www.nict.go.jp/JST/http.html)に
      「アクセス過多が発生した場合には予告なくサービスの停止を行います。」と書いてあるので
      舌足らずではありますが、間違ってはいないと思います。

      • by Anonymous Coward

        後半はページタイトルなのか。そりゃ知らなかったら意味が通じない。

  • by Anonymous Coward on 2020年07月20日 17時00分 (#3855580)

    NTPは、HTTPSのように安全ではなく、なりすましが容易にできてしまいます。

    例えば、出社・退社の時刻を管理するタイムカードシステムがあって、そのコンピュータがNTPで時刻同期していたとします。

    同じLAN内からは、ARPスプーフィングというテクニックでNTPサーバを詐称することが簡単にできてしまい、
    偽のNTPサーバと同期させる → 出社登録する → ARPスプーフィングを止めてもとのNTPサーバと同期させる
    とすることにより、勤務時間を不正に改竄することができます。

    ログからバレて処分を受けるかもしれないのにタイムカード改竄なんて有り得ないって?
    だったら、気に入らない同僚を冤罪に陥れるために、同僚の登録前後で改竄するなんてことも有り得ます。

    DNS等も over HTTPS にしようというのが時代の流れなのに、今更脆弱なNTPに戻すなんてナンセンスです。

    ここに返信
    • by ilonasive (6257) on 2020年07月20日 21時42分 (#3855761)

      OpenNTPDでは、あなたの指摘したような問題を解決するための仕組みが組込まれています。

      設定ファイルntpd.conf (抜粋)

      # use a random selection of NTP Pool Time Servers
      # see http://support.ntp.org/bin/view/Servers/NTPPoolServers
      servers pool.ntp.org
       
      # get the time constraint from a well-known HTTPS site
      constraint from "9.9.9.9"         # quad9 v4 without DNS
      constraint from "2620:fe::fe"     # quad9 v6 without DNS
      constraints from "www.google.com" # intentionally not 8.8.8.8

      OpenNTPDは設定ファイル中のconstraint行で指定されたウェブサーバと通信を行い、証明書の検証で使われるタイムスタンプを取得します。

      このタイムスタンプは精密なものである必要はありませんが、「検証された時刻」となっています。

      次に、servers行で指定されたサーバとNTPプロトコルで通信を行い、時刻の同期を取ろうとします。

      この時、NTPサーバが返してきたタイムスタンプがTLS通信で取得されたタイムスタンプと大きく異っている場合、そのNTPサーバは時刻の参照元としては採用されません。

    • by Anonymous Coward on 2020年07月20日 22時13分 (#3855787)

      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 なんて言い出すほうが、よっぽどナンセンスです。

      • by Anonymous Coward

        ntpsecって、どれくらい普及してるんですか。

    • Authenticationくらいありますよ、いくらなんでも(設定しているとは言ってない)
      • by Anonymous Coward

        一応あることにはあるけど、
        ・対応しているタイムカード専用機は少ない
        ・対応していてもMD5のみ
        というのが現状

        • by Anonymous Coward

          httpsに対応しているタイムカード専用機のほうが少ない気がします。

    • by Anonymous Coward

      何でslewモード使ってないの?

    • by Anonymous Coward

      NTPはそんなに頻繁に時刻調整するものではないし、ログからバレて処分されるのはタイムカード改ざんに対してではなくARPスプーフィングによるNTPサーバーへの攻撃に対してでしょう。

      • by Anonymous Coward

        ARPスプーフィングを誰がやったかなんて特定は事実上不可能ですよ
        特に鞄の中に入れたWi-Fi端末(無論MACアドレスは詐称)からやったら防犯カメラにも何も映らないしね

        • by Anonymous Coward

          勝手端末を社内LANにつなげられる時点で脆弱。
          さらにその設定ではARPスプーフィングを止めることができない。

    • by Anonymous Coward

      arp が問題なんだから、IPv6 にして NTP 使えばいい。

  • by Anonymous Coward on 2020年07月20日 16時40分 (#3855564)

    NTPなど、1900年1月1日からの積算秒数で時間を表現するシステムもあり、符号なし32ビットの値が2036年2月7日6時28分15秒 (UTC) を超えるとオーバーフローすることによって問題が発生する(→2036年問題)。

    ここに返信
    • by Anonymous Coward

      2036年ごろには
      「NICTへのNTPアクセスのうち1.3%は2036年問題非対応のバージョン」
      みたいな記事が立つけど、実際にはほとんどが疎通確認やクライアント側で対応済みで別に問題が起きない…
      みたいな落ちが目に見えるな。

      古いルーターが無駄に時間が狂ってるけど別に問題なく動作したままとかそういうのはありそう。

    • by Anonymous Coward

      ウィキペディアの続き

      SNTPv4を定めたRFC 4330には、最上位ビットが0の場合は時刻が2036年から2104年の間であるとみなして、2036年2月7日6時28分16秒 (UTC) を起点として計算することで2036年問題を回避する方法が書かれている。

      最上位ビットの意味を読み替えるよう定期的にRFCを更新していけば安心!

  • by Anonymous Coward on 2020年07月20日 18時22分 (#3855647)

    お知らせによると

    以下にはこの一元化及び時限的な停止による影響はありません

    ✔ 当機構のhttp/httpsによる時刻配信を利用していないほとんどのスマートフォン・PC等のアプリケーション
    ✔ ご使用の端末と標準時の時刻差を表示する以下のページ時刻合わせページ(下図)
    https://www.nict.go.jp/JST/JST5.html [nict.go.jp]

    とのことですが、二つ目の時刻合わせページは[ランダムな16進数].nict.go.jp/cgi-bin/jsonから時刻を取得しているみたいなので、この(隠し?)APIは維持されるということなんですかね?

    ここに返信
  • by Anonymous Coward on 2020年07月20日 22時06分 (#3855782)

    時代が変わったのだからバージョン上げてセキュアになってもいいんじゃない?。
    https://tools.ietf.org/html/rfc1305 [ietf.org] にコメント出してもいいのよ。知らんけど。

    #アレなんでアレでよろしく(軽いなあー

    ここに返信
    • by Anonymous Coward

      NTPS(NTP over SSL) で行くか NoH(ntp-over-https) で行くか。問題はそこからだ。

  • by Anonymous Coward on 2020年07月21日 9時36分 (#3855992)

    決して美しい実装ではなかったので、原点回帰って意味では望ましい傾向だと思う。

    コネクション複数張るとか時代遅れなプロトコルはともかく、単にFWを抜けられないからって理由でHTTPに載せてるものは本来の形に戻すべき。
    あと企業のFWも無意味なアウトバウンド方向の制限をやめるべき。どっちにしろ突破される。

    ここに返信
  • by Anonymous Coward on 2020年07月21日 11時40分 (#3856075)

    HTTPSで時刻同期するためにはwebサーバの証明書を検証する必要があって、
    証明書を検証するには現在時刻とNot Before/Not Afterを比較する必要があって、
    比較するためには現在時刻が正しく設定されていないといけない。

    ここに返信
  • by Anonymous Coward on 2020年07月21日 12時07分 (#3856092)

    なお停止時間は徐々に長時間化していくとしている

    これ、NTP 的だなぁ。期間を長めにとって宣言する、で良い気がする。

    以下余談。NTP って上りと下りの速度が同じ事が前提って聞いた気がするが、どうなのかな

    ここに返信
    • by Anonymous Coward

      速度と言っても帯域幅じゃなくてレイテンシの方だと思うが、
      レイテンシが大幅に偏ってるケースが一体どれほどあるか、
      偏っててもそれをどうやって検出するというのか、
      検出できて補正できてもそこにどの程度の効果があるのか。

      まぁ理屈の上では帯域幅違えば同時に送り始めても帯域幅広いほうが先に宛先やらパケット末尾やらを読んで中継できるけど、ホップ数のほうが影響大きいし、
      レイテンシが大幅に偏る為には行きと帰りで遅延の全然違う経路を通らなないと厳しいだろうし、
      検出するには一々トレースルート掛けなきゃだし、それも当てにならん上に双方向分必要だし、
      そんだけ頑張って何ミリ秒正確になるのか。パソコンとか大抵の機器じゃ早々にそれ以上に狂ってしまう予感。

      多分ほぼ意味がない。

typodupeerror

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

読み込み中...