: SecOSStatusWith error:[-34018] Error Domain=NSOSStatusErrorDomain Code=-34018 "client has neither application-identifier nor keychain-access-groups entitlements" UserInfo={NSDescription=client has neither application-identifier nor keychain-access-g
どうしてそんなものが一度は通った (スコア:2)
エンタープライズデプロイ用の特定アプリならともかく、なぜ一般向けにそんな仕様が認められたのだろう。
そして広告ブロックアプリ以外にどんなものが出ていたのか
Re:どうしてそんなものが一度は通った (スコア:5, 参考になる)
HIRATA Yasuyuki
Re: (スコア:0)
というかそもそも論としてルート証明書をインストールするAPIが一般アプリから叩けてしまうこと自体が仰天ものだと思う
Re:どうしてそんなものが一度は通った (スコア:3)
HIRATA Yasuyuki
Re: (スコア:0)
構成プロファイル(MVNOを使うときとかに必要になるやつ)をインストールさせるみたいだよ。
とりあえずこの事件でわかったのは、そういうことができるならキャリアは工場出荷時の構成プロファイルでMITM証明書をインストールして「通信の最適化」とかもう間違いなくやるな、ということか
Re: (スコア:0)
Windowsデスクトップと大して変わりないじゃん。Windowsストアアプリはさすがにまともになってるが、デスクトップアプリがインストールしたルート証明書の影響を受けることに変わりはない。安全を追求するならWindows RTのようにデスクトップアプリは全廃するほかないが、残念ながらユーザーの支持を得られなかった。
Re:どうしてそんなものが一度は通った (スコア:1, 参考になる)
> Windowsデスクトップと大して変わりないじゃん。
Apple信者は無理やりWindowsまで道連れにしようとしてMacさんを地獄に引きずり込んだ、まで理解できました。
ありがとうございました。
iOSもMacも駆除するしかないですねこりゃ
Re: (スコア:0)
携帯とデスクトップをごっちゃにして、ごまかす作戦ですか？
Re: (スコア:0)
この操作って Windows デスクトップの制限された User でも有効なんですか？
rooted なユーザで可能なのは Windows/Android/iOS どれも同じだと思いますが
Re:どうしてそんなものが一度は通った (スコア:2)
Windows/OSXはともかく普通にAndroid/iOS使ってる分にはrootedユーザではないのでは？
今回の問題にはルート証明書のインストールにどのくらいの権限が必要かというのがありますけど。
Google、Yahoo、Pinterestの各アプリで使用している広告ブロック方法 (スコア:0)
各アプリに広告ブロック機能があるみたい。典型的な悪文。
色々よくわからない点が (スコア:0)
なぜ「独自のルート証明書を使用していると中間者攻撃が懸念される」かがわからない。
Re:色々よくわからない点が (スコア:1)
件の広告ブロックアプリは通信内容を途中経路で改竄します。
しかし改竄するとhttpsでは改竄を検知してブラウザはエラーを表示し結果は表示されません。
それを防ぐため独自のルート証明書をインストールさせ通信に使用する証明書を差し替えてして通信しています。
それでは実際に途中経路で改竄された場合は誰が改竄を検知するのでしょうか？
原理的には証明書を途中で差し替える前でしか行えないので広告ブロックアプリしか行えません。
それらが正しく実装されていると言えるでしょうか？
その他にも、広告ブロックアプリアプリを解析する事により独自の証明書で暗号化するために持っているサーバー証明書を得ることができてしまいます。
その証明書を使って途中経路で改竄すると独自の証明書のインストールが行われている間は正しい証明書のチェックを行えません。
そもそも悪意のあるアプリが独自のルート証明書をインストールした場合は言うまでもありませんね
などの懸念があります。
Re: (スコア:0)
> 独自の証明書で暗号化するために持っているサーバー証明書を得ることができてしまいます。
> その証明書を使って途中経路で改竄すると独自の証明書のインストールが行われている間は正しい証明書のチェックを行えません。
サーバ証明書を得ることは簡単でしょうが、秘密鍵なくサーバ証明書だけを使って、
どうやって途中経路で改ざんするんでしょうか。
この仕組みの安全性は、独自の独自ルート証明書と秘密鍵をもって、
SSLの復号と再暗号化を行う部分の機器のセキュリティ次第であり、
この手法を使っていれば悪い、ということは一概には言えないと思います。
逆に、この手法はそ
Re: (スコア:0)
>この手法はそもそも証明書が「独自ルート証明書」でなければ安全か、といえば決してそんなことは言えません。途中経路の機器が持っているのが公的証明書であっても、途中経路の機器の安全性はなんら担保されないためです。
(広告ブロックの対象としたいURL)すべてにマッチする公的証明書は取得できないためそんなことはできません。
Re: (スコア:0)
iOS8まではうまく行っていた、独自ルート証明書＋クライアント証明書
による、Appacheアクセス制御（SSLVerifyClient require）が、
iOS9になると、下記エラーが出て（xCodeのデバイスから取得）先に
進まなくなっています。
Safariでクライアント証明書必須の当該H/Pを見るだけで、下記エラーに
なっています。
: SecOSStatusWith error:[-34018] Error
Domain=NSOSStatusErrorDomain Code=-34018
"client has neither application-identifier
nor keychain-access-groups entitlements"
UserInfo={NSDescription=client has neither
application-identifier nor keychain-access-g
Re: (スコア:0)
p12をベタに配ってないでiPhone構成ユーティリティでmobileconfig作れ
Re: (スコア:0)
サーバ証明書を得ることは簡単でしょうが、秘密鍵なくサーバ証明書だけを使って、
どうやって途中経路で改ざんするんでしょうか。
アプリ内で改竄して再証明している以上アプリに秘密鍵が含まれているはずです。
このような、独自証明書を使って一度SSLを解読する方法は、Proxy利用するネットワーク製品や
セキュリティ上、外部へのSSL通信を解析する必要のあるセキュリティ製品等では一般的に行われています。
（もちろん、企業であれば管理者、またはユーザの同意あっての利用です。）
それはそのセキュリティ機器が接続先の証明書をチェックしているはずです。していないのであれば欠陥品です。
独自のルート証明書をインストールするアプリの中で
・ユーザー毎に外部から推測できない異なる秘密鍵
Re: (スコア:0)
アプリ内で改竄して再証明している以上アプリに秘密鍵が含まれているはずです。
VPNを使っているので、このアプリ内に暗号鍵は無い筈です。
Re: (スコア:0)
広告ブロックアプリがローカルにVPNサーバーを立てているのでは？
iOSデバイスを持ってないので確認できませんが、少なくともAndroid版のAdblock PlusはlocalhostのVPNサーバーの設定を追加します
通信内容を改竄するサーバーを開発者が用意する方法だと、通信量を考えるととてもペイできるとは思えませんし、私は広告ブロックのためだけに管理者が改竄、盗聴し放題のサーバーを通すなんて嫌ですね
Re: (スコア:0)
Certificate pinningでググれ
Re: (スコア:0)
VPN利用のために発行されたルート証明書がなぜ中間者攻撃に使われるのかわからない。
Certificate pinningって発行すべきでない認証局が発行した証明書を検知するためのものではない？
Re: (スコア:0)
あなたはそう思っていればいいってことでｗ
#無知なのはどーしよーもないからねー