SSL/TLSライブラリの正しい使い方（もしくは、コモンネームの検証について）
スマホアプリの市場拡大に伴い、直接SSL/TLSライブラリを使用するプログラムを書く機会も増えてきている今日この頃かと思います。 SSL/TLSライブラリを使う際には、接続確立時にサーバの認証を正しく行う必要があります。具体的には、クライアントプログラムで以下の２種類の検証を行うことになります。 SSL/TLSライブラリがサーバの証明書の検証に成功したこと サーバの証明書に含まれるコモンネーム注1が接続しようとしたサーバと同一であること 前者については、OpenSSLの場合はSSL_CTX_set_verifyの引数にSSL_VERIFY_PEERを指定するなどして、ライブラリ側で処理を行わせることが可能です（証明書の検証に失敗した場合はSSL_connectがエラーを返します）。 一方、後者についてはSSL/TLSライブラリによって差があり、検証機能を有効にするために特別な呼出が必要だっ
WebとiOSアプリでパスワードを共有する - 24/7 twenty-four seven
iOS 8からWebサービスとアプリ間でiCloudキーチェーンを通じてパスワードなどアカウント情報を共有できるようになりました。 （ただし、現状ではiCloudキーチェーンを使えるのはSafariのみのため、MacのSafariとiOSアプリの間に限る） 昨今ではそれぞれ別のサービスで同じパスワードを再利用せず、サービスごとに固有のできればランダムなパスワードを登録して、パスワードマネージャで管理することが推奨されています。 Webサービスを使うだけならブラウザのパスワード管理などを利用すればいいのですが、そのサービスのiOSアプリを利用しようとするとパスワードを調べるのが大変でした。 iOS 8では（Safari限定ではありますが）Webサービスで入力してキーチェーンに保存したアカウント情報を、iOSアプリでも利用することができます。 パスワードなど機密性の高い情報を共有するため、どの
ImperialViolet - Apple's SSL/TLS bug
Yesterday, Apple pushed a rather spooky security update for iOS that suggested that something was horribly wrong with SSL/TLS in iOS but gave no details. Since the answer is at the top of the Hacker News thread, I guess the cat's out of the bag already and we're into the misinformation-quashing stage now. So here's the Apple bug: static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bo
iOS実機のSSL通信をプロキシによって傍受したり改ざんする方法 - Qiita
はじめに スマートフォンアプリ開発でAPIを介しWeb/APIサーバーとやりとりをする場合、「httpsを使っていれば通信はユーザーにバレない」なんてことはなく、Webアプリでツールを使ってできるのと同じようにユーザーには通信内容の確認や改竄などができます。 そのため、そのことを前提にアプリやサーバーAPIの設計と実装を行わない場合、アプリ利用者によるゲームスコア結果送信の改竄や、ソーシャルゲームにおけるレイドボスなどへのダメージ操作、ECサイトアプリでの購入操作なども可能になってしまいます。 また、最近自分は「無料で音楽聴き放題!! - ネットラジオ」というアプリをリリースしたのですが、このアプリに導入するスタティックリンクライブラリが不明な外部サーバーへ通信していないか、SSLを使用しているつもりがそうでない通信をしてしまっていないかのチェックをするため、自分はmitmproxyという
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
