LINE「独自暗号化」のメリットと安全性について
LINEが使用している「独自の」暗号化手法について、情報が一部開示（参照：LINEの暗号化について « LINE Engineers' Blog）され、Twitterでもやりとりをしたので、まとめてみる。 ■なぜTLSを使わないか TLSではなく、１パスのメッセージ暗号化を使っている理由については、Adopting SPDY in LINE – Part 2: The Details « LINE Engineers' Blogに以下のような記載があり、TLSを使うことによるレイテンシの増加を懸念しているためと考えられる。 3G mobiles networks normally operate at slow speeds. （中略）If the connection changes modes when the user sends a message, we are forced t
GoogleによるOpenSSLのfork、BoringSSLを試す。 - ぼちぼち日記
1. はじめに、 先日、Chrome で 「Issue 401153002: Switch to BoringSSL. (Closed)」 という変更が行われました。これは、従来の Android向け Chrome では OpenSSL を利用していたのですが、今回これをGoogleがOpenSSLをforkしたBoringSSLに切り替えたことになります。 BoringSSLの発表からわずか1か月ぐらいですが、何回か Revert された末ようやく切り替えが成功したようです。 今回 BoringSSL を試しに少し使ってみましたので、そのレポートしてみたいと思います。 2. BoringSSLとは何か BoreingSSLがどういうもので、なぜOpenSSLをforkしたかは、GoogleのセキュリティExpert agl さんのブログ「ImperialViolet - BoringSS
グーグル、OpenSSLの新たなforkとして「BoringSSL」発表
グーグルがOpenSSLのforkを発表、独自の実装にOpenSSL側の変更をマージする体制を採る。OSSでの展開はしない方針だという。 米グーグルが、オープンソースのSSL/TLS実装「OpenSSL」から新プロジェクトの「BoringSSL」を派生させた。同社の研究者アダム・ラングリー氏が2014年6月20日、自身のブログ「ImperialViolet」で明らかにした。 ラングリー氏によると、グーグルでは「Heartbleed」と呼ばれる重大な脆弱性が発覚する以前からOpenSSLのコードを検証し、何年にもわたって多数のパッチを使用してきた。この中にはOpenSSLのメインレポジトリに採用されたものもある一方で、OpenSSLが保証するAPIやABIの安定性とかみ合わないものや、やや実験的過ぎるものも多かったという。 しかし、AndroidやChromeなどの製品でそうしたパッチのサブ
stunnel - Wikipedia
stunnel(スタンネル) は、フリーなマルチプラットフォーム対応のプログラムであり、汎用TLS/SSLトンネリングサービスを提供する。 stunnel は、TLSやSSLにネイティブで対応していないクライアントサーバシステムに安全な暗号化されたコネクションを提供するのに利用できる。各種オペレーティングシステム上で動作し、ほとんどのUnix系OSとWindowsでも動作する。TLS/SSLプロトコルの実装にはOpenSSLやSSLeayなどのライブラリが別途必要である。 stunnel は、TLSやSSLコネクションの認証にX.509公開鍵証明書を使える。オプションとして、クライアントも証明書で認証できる。 libwrapとリンクした場合、プロキシ-ファイアウォールサービスとしても構成可能である。 stunnel はGNU General Public License でライセンスされて
stunnel
Stunnel is a proxy designed to add TLS encryption functionality to existing clients and servers without any changes in the programs' code. Its architecture is optimized for security, portability, and scalability (including load-balancing), making it suitable for large deployments. Stunnel uses the OpenSSL library for cryptography, so it supports whatever cryptographic algorithms are compiled into
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
OpenBSD、怒りのコミット
OpenSSLのheatbeatバグの対応のため、OpenBSDはOpenSSLのheatbeatを無効にするコミットをした。ただし・・・ src/lib/libssl/ssl/Makefile - view - 1.29 SegglemannのRFC520 heatbeatを無効化。 あのまともなプロトコルひとつ制定できないIETFの無能集団が、超重要なプロトコルで64Kの穴をこしらえるとか、マジであきれてものも言えねーわ。奴らはマジこの問題を本気で検証すべきだろ。なんでこんなことをしでかしたのか。こんな事態を承認した責任ある連中を全員、意思決定プロセスから取り除く必要がある。IETF、てめーは信用なんねぇ。 このコミットは、Makefileの中で、OpenSSLでheatbeatを無効にするマクロを定義するよう、コンパイラーオプションを指定するものだ。ただし、無効にするマクロは、OPE
Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について
■Heartbleedのリスクと善後策 Heartbleedは、攻撃者が一定の条件を満たすOpenSSLが動作しているサーバの、任意位置のメモリを外部から読み出すことができてしまうという脆弱性です。具体的には、以下のようなリスクが想定されています。 秘密鍵の漏洩による、偽サイトの出現（あるいは中間者攻撃） 秘密鍵の漏洩により、（過去のものを含む）パケットキャプチャの解読 サーバの同一プロセスが行った処理に関連する（他のユーザーのパスワードやセッションキーを含む）データの漏洩 漏洩した秘密鍵を用いた攻撃には、ユーザーを偽サイトへ誘導できたり、パケットの経由点を管理しているなどの、経路上の要件が必要になります。他のユーザーのデータの漏洩については、経路上の要件は不要な一方、攻撃の実施に近いタイミングでサーバにアクセスしたユーザーのデータしか漏れない、という違いがあります。 どこまで対策を施すべ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
