Charlesを使うとhttpsであろうとリクエストの内容が覗けてしまうという記事を読みました。  
<http://qiita.com/HIkaruSato/items/1f66c1a189bf9c19f838>

ATSの設定はしてあるのですが、それでも覗けてしまうものでしょうか？  
そうであれば対策できる方法があればご教授いただければ幸いです。
CC BY-SA 3.0
2016-08-05T08:22:23.977
28084
2016-08-08T06:30:03.707
18396
question
ios
iOSのパケットキャプチャ対策、ATSについて
インフラ的な視点で回答します。

charlesは、端末(iPhoneなど）・ブラウザを代行して、  
プロキシがSSLの複合・暗号化をする、というものです。

これは、一般的なプロキシでも同様の動作をすることができるため、  
原則対策はありません。

このため、アプリケーション側ではキャプチャされても  
可読できない情報とする、ワンタイムパスワードのような乱数と文字列を結合して  
画面遷移をキャプチャしても再現できないようにするなどの工夫を行って、回避する形になろうかとおもいます。
CC BY-SA 3.0
2016-08-05T12:57:43.500
28088
2016-08-05T12:57:43.500
18398
28084
answer
Charlesなどのプロキシや中間者攻撃によるネットワーク通信の傍受を防ぐにはSSL Pinningという方法があります。  
もしiOSアプリケーションの接続先が特定のAPIのみなど決まっているのであれば、SSL
Pinningを用いてアプリケーション内で特定の証明書のみ有効であることを検証することでCharlesなど独自の証明書を用いた通信を失敗させることができます。

CharlesのドキュメントにもSSL Pinningが行われている場合にはSSLの通信は失敗する旨が書かれています。

> Note that some apps implement SSL certificate pinning which means they
> specifically validate the root certificate. Because the app is itself
> verifying the root certificate it will not accept Charles's certificate and
> will fail the connection. If you have successfully installed the Charles
> root SSL certificate and can browse SSL websites using SSL Proxying in
> Safari, but an app fails, then SSL Pinning is probably the issue.

<https://www.charlesproxy.com/documentation/faqs/ssl-connections-from-within-
iphone-applications/>

もちろんSSL
Pinningを行うことのデメリットはあり、Pinningの方法にもよりますが、サーバ側で証明書をアップデートした場合は、クライアントもアップデートが必要であるとか、本来ユーザー側の権利として認められている通信内容の確認ができなくなるということも問題として言われています。
CC BY-SA 3.0
2016-08-08T01:30:44.770
28112
2016-08-08T06:30:03.707
2016-08-08T06:30:03.707
5519
5519
28084
answer