アカウント名:
パスワード:
> 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を超えてデータが残る現象を浸透とか呼んで肯定しちゃう世界)ので、警戒して損はありません。
# そもそも携帯電話がクライアント認証をサポートしてくれれば万事解決なのでしょうけれど
> 対タンパ性を十分とするならガラケー(の、少なくとも端末ID周り)に耐タンパ性なんかないよ。ガラケーの認証は「電波法で禁止しておけば、不正改造する奴などいるはずない」という前提のもとに成り立つもの。その想定がいかにガラパゴスなものかは最近ソニーが身をもって実証してくれたでしょ(訴訟で恫喝すればみんなビビって手を出さなくなるに違いない)。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
書き方がおかしい。 (スコア: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を超えてデータが残る現象を浸透とか呼んで肯定しちゃう世界)ので、警戒して損はありません。
# そもそも携帯電話がクライアント認証をサポートしてくれれば万事解決なのでしょうけれど
Re: (スコア:0)
> 対タンパ性を十分とするなら
ガラケー(の、少なくとも端末ID周り)に耐タンパ性なんかないよ。
ガラケーの認証は「電波法で禁止しておけば、不正改造する奴などいるはずない」という前提のもとに成り立つもの。その想定がいかにガラパゴスなものかは最近ソニーが身をもって実証してくれたでしょ(訴訟で恫喝すればみんなビビって手を出さなくなるに違いない)。
Re: (スコア:0)
（ケータイWebに趣味や仕事で関わっている人の間では）常識だと思っていたが…、
まさか、auはケータイWebの世界でお仕事してる人達に、
「対スマフォも従来のauガラケーと同様にサービス出来ますよ」
等と間違った事をアピールしてしまったんだろうか？
EZ番号（旧称サブスクライバID）について妙な説明をしない限り、
あの一文は必要ないよなぁと思ったのだが、
あれ？ EZ番号の説明が見当たらない…