アカウント名:
パスワード:
> EZ 番号と併せて EZ サーバの IP アドレス等、って言い方をするってことは、auのスマートフォンはEZサーバを経由しないってことでしょ?現にグローバルIPアドレスが振られているわけだしさ。正しくは「EZ 番号は(対タンパ性を十分とするなら)auのガラケー以外では詐称可能なため」じゃないの。
# そもそもHTTPでもHTTPSでも同じ値が送信されるX_UP_SUBNO HTTPヘッダでユーザー認証とか狂気の沙汰。
IPアドレス帯域 [kddi.com]
※EZweb及びPCSVサービス向上のため、IPアドレスは予告なく変更させていただきますのでご了承ください。なお、アドレス増減の際には、本ページ上にて周知させていただきます。※本情報はEZサーバ、PCSV以外のホストによる下記表のIPアドレスでのアクセスがないことを保証するものではありません。
まあ、ソフトウェアの免責事項とみたいなものだろうけど、そろそろ保障とは言わなくても保証くらいしてほしいものだ。
HTTPS はサーバ(ドメイン)の認証は出来るが、コンテンツの認証はできない。ちょっと前には Gumblar による改竄があり、あるドメイン用のサーバにアップされているファイルが正しいものかなんて分からない、という事が言える。やるなら PGP 等で署名した IP アドレスリストを載せる必要がある。もちろん、その署名者の検証用の鍵が流通している必要も。自分も、入手したソフトウェアの tarball 等は、署名がある限り極力 verify してます。
# 無論、署名の秘密鍵が汚染されていない必要があるが…# sftpやscp用でアクセス制御がまともに出来る Server ソフトウェアが# 存在しないため、まだまだ web コンテンツのアップにて ftp の使用がされているからねぇ…。# 自分の知っている案件だと、One time password を使用していてほぼ対応不要だった例も。
そこまで求めてないですよ。携帯電話のキャリア側が汚染される事態まで想定しだすと、IPアドレスが正しくてもキャリア側で汚染されたサーバからの接続の可能性が否定できなくなりますから、ハナから負けです。
攻撃対象はコンテンツ提供者です。コンテンツ提供サーバの周辺でIPアドレス偽造が行われれば(SSLを使っていようと普通は)打つ手ナシですが、DNS汚染や開発者の利用する回線でのIPアドレス偽造はSSLで防衛可能です。DNSは結構穴だらけで運用されている(設定ミスでTTLを超えてデータが残る現象を浸透とか呼んで肯定しちゃう世界)ので、警戒して損はありません。
# そもそも携帯電話がクライアント認証をサポートしてくれれば万事解決なのでしょうけれど
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
書き方がおかしい。 (スコア:1)
> EZ 番号と併せて EZ サーバの IP アドレス等、
って言い方をするってことは、auのスマートフォンはEZサーバを経由しないってことでしょ?
現にグローバルIPアドレスが振られているわけだしさ。
正しくは「EZ 番号は(対タンパ性を十分とするなら)auのガラケー以外では詐称可能なため」じゃないの。
# そもそもHTTPでもHTTPSでも同じ値が送信されるX_UP_SUBNO HTTPヘッダでユーザー認証とか狂気の沙汰。
Re: (スコア:0)
> って言い方をするってことは、auのスマートフォンはEZサーバを経由しないってことでしょ?
加えていうなら、auのスマートフォンがEZ番号を送出することがなく、
auのガラケーがEZサーバを介さずにHTTP(S)アクセスすることもないです。
つまり、EZサーバ経由以外のEZ番号は信用するな、と。
でも、EZサーバの帯域って公式コンテンツ提供者以外にも公開されてたっけ?
センセが吊るすって言ってるのは、そこか・・・?
Re:書き方がおかしい。 (スコア:1)
IPアドレス帯域 [kddi.com]
Re: (スコア:0)
※EZweb及びPCSVサービス向上のため、IPアドレスは予告なく変更させていただきますのでご了承ください。なお、アドレス増減の際には、本ページ上にて周知させていただきます。
※本情報はEZサーバ、PCSV以外のホストによる下記表のIPアドレスでのアクセスがないことを保証するものではありません。
まあ、ソフトウェアの免責事項とみたいなものだろうけど、そろそろ保障とは言わなくても保証くらいしてほしいものだ。
Re: (スコア:0)
# あと、いい加減キャリア各社はこの情報を機械可読な形式で公開してほしい
Re: (スコア:0)
HTTPS はサーバ(ドメイン)の認証は出来るが、コンテンツの認証はできない。
ちょっと前には Gumblar による改竄があり、あるドメイン用のサーバにアップされている
ファイルが正しいものかなんて分からない、という事が言える。
やるなら PGP 等で署名した IP アドレスリストを載せる必要がある。
もちろん、その署名者の検証用の鍵が流通している必要も。
自分も、入手したソフトウェアの tarball 等は、署名がある限り極力 verify してます。
# 無論、署名の秘密鍵が汚染されていない必要があるが…
# sftpやscp用でアクセス制御がまともに出来る Server ソフトウェアが
# 存在しないため、まだまだ web コンテンツのアップにて ftp の使用がされているからねぇ…。
# 自分の知っている案件だと、One time password を使用していてほぼ対応不要だった例も。
Re: (スコア:0)
そこまで求めてないですよ。
携帯電話のキャリア側が汚染される事態まで想定しだすと、IPアドレスが正しくてもキャリア側で汚染されたサーバからの接続の可能性が否定できなくなりますから、ハナから負けです。
攻撃対象はコンテンツ提供者です。
コンテンツ提供サーバの周辺でIPアドレス偽造が行われれば(SSLを使っていようと普通は)打つ手ナシですが、DNS汚染や開発者の利用する回線でのIPアドレス偽造はSSLで防衛可能です。
DNSは結構穴だらけで運用されている(設定ミスでTTLを超えてデータが残る現象を浸透とか呼んで肯定しちゃう世界)ので、警戒して損はありません。
# そもそも携帯電話がクライアント認証をサポートしてくれれば万事解決なのでしょうけれど