New attack bypasses HTTPS protection on Macs, Windows, and Linux
A key guarantee provided by HTTPS encryption is that the addresses of visited websites aren't visible to attackers who may be monitoring an end user's network traffic. Now, researchers have devised an attack that breaks this protection. The attack can be carried out by operators of just about any type of network, including public Wi-Fi networks, which arguably are the places where Web surfers need
Feature: Squid-in-the-middle SSL Bump
🔗 Feature: Squid-in-the-middle SSL Bump Goal: Enable ICAP inspection of SSL traffic. Version: 3.1 to 3.4. Developer: AlexRousskov, Christos Tsantilas More: See also dynamic SSL certificate generation and origin server certificate mimicking features. 🔗 Details This feature was replaced in Squid-3.5 by peek-n-splice This feature was replaced in Squid-3.3 by server-first Squid-in-the-middle decrypt
HTTPS 化する Web をどう考えるか - Block Rockin’ Codes
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
HTTP/2から見えるTLS事情 - あどけない話
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
iOS実機のSSL通信をプロキシによって傍受したり改ざんする方法 - Qiita
はじめに スマートフォンアプリ開発でAPIを介しWeb/APIサーバーとやりとりをする場合、「httpsを使っていれば通信はユーザーにバレない」なんてことはなく、Webアプリでツールを使ってできるのと同じようにユーザーには通信内容の確認や改竄などができます。 そのため、そのことを前提にアプリやサーバーAPIの設計と実装を行わない場合、アプリ利用者によるゲームスコア結果送信の改竄や、ソーシャルゲームにおけるレイドボスなどへのダメージ操作、ECサイトアプリでの購入操作なども可能になってしまいます。 また、最近自分は「無料で音楽聴き放題!! - ネットラジオ」というアプリをリリースしたのですが、このアプリに導入するスタティックリンクライブラリが不明な外部サーバーへ通信していないか、SSLを使用しているつもりがそうでない通信をしてしまっていないかのチェックをするため、自分はmitmproxyという
解読不可能のはずの「iMessage」が実は解読可能でIDやパスワードも読めることが判明
エドワード・スノーデン氏によって暴露されたNSAのスパイ行為事件において、Appleから「通信は暗号化されているのでAppleを含む第三者が通信内容を知ることは不可能」とされていたiMessageやFaceTimeが実はApple自身によって解読可能だったことが判明しました。さらに、第三者が通信を傍受することで、MITM攻撃(中間者攻撃)を可能にする危険も含まれており、Appleが以前から公言してきた「iMessageやFaceTimeの通信には『エンド・トゥ・エンド』の暗号化を行っているので、受信者と送信者以外は内容を見ることはできない」とする説明に相反するものになっています。 iMessage Privacy http://blog.quarkslab.com/imessage-privacy.html iMessage_privacy.pdf (PDFファイル：約8MB) http:
Charlesを使ってiPhoneのhttps通信をキャプチャする - murapong's blog
iPhoneアプリのhttps通信をキャプチャするにはCharlesを使うと楽です。Windows版、Mac版、Linux版がありますが、今回はMac版で確認しています。トライアル版（30日）は30分毎にCharlesの再起動が必要となりますが、とりあえずはこれで大丈夫です。 事前準備 ifconfigコマンドなどでCharlesを動かすMacのIPアドレスを確認しておく。 Charlesのダウンロード／インストール Charlesの公式サイトよりダウンロードする。Macの場合はダウンロードしたzipファイルを解凍し、アプリケーションフォルダに移動させればインストール完了です。 Charlesの設定 Charlesはデフォルトだとhttps通信のキャプチャが無効になっているため有効にします。 Charlesを起動し「Proxy」→「Proxy Settings...」をクリック。 「SSL
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
通信の安全を守るためにエンジニアができること
TLS に新たな欠陥：被害者になりすますことが可能に～研究者が暴いた、暗号化プロトコルを騙す方法――及び、それを修復する方法（The Register） | ScanNetSecurity