Starting with Chrome 13, we'll have HTTPS pins for most Google properties. This means that certificate chains for, say, https://www.google.com, must include a whitelisted public key. It's a fatal error otherwise. Credit goes to my colleague, Chris Evans, for much of this. The whitelisted public keys for Google currently include Verisign, Google Internet Authority, Equifax and GeoTrust. Thus Chrome
Transport Layer Security (TLS) False Start draft-bmoeller-tls-falsestart-00 Abstract This document specifies an optional behavior of TLS implementations, dubbed False Start. It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. The TLS False Start feature leads to a latency reduction of one round trip for certain handshakes. Status of this Memo This I
(This is a write up of the talk that I gave at Velocity 2010 last Thursday. This is a joint work of myself, Nagendra Modadugu and Wan-Teh Chang.) The ‘S’ in HTTPS stands for ‘secure’ and the security is provided by SSL/TLS. SSL/TLS is a standard network protocol which is implemented in every browser and web server to provide confidentiality and integrity for HTTPS traffic. If there's one point tha
本のページをめくるように、どんなWebページも素早く表示できるようにする。グーグルは以前からWebの高速化に取り組んできました。 6月22日から、米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」では、グーグルのUrs Hölzle氏がWebの高速化技術について「Speed Matters」（スピードの重要性）というセッションで紹介ています。 Webを高速化するためにどのような技術があり、あるいはどのような技術が検討されているのか、このセッションの内容を紹介しましょう。 スピードは重要だ 私が話そうとしているのは、「Speed matters｣（スピードの重要性）についてだ。Webは空飛ぶジャガイモより速くなれるだろうか？ どのくらい速くなれるだろうか？ （参考：オペラがやってくれた！ グーグルの空飛ぶジャガイモに対抗）
WebOS Goodies へようこそ！ WebOS はインターネットの未来形。あらゆる Web サイトが繋がり、共有し、協力して創り上げる、ひとつの巨大な情報システムです。そこでは、あらゆる情報がネットワーク上に蓄積され、我々はいつでも、どこからでも、多彩なデバイスを使ってそれらにアクセスできます。 WebOS Goodies は、さまざまな情報提供やツール開発を通して、そんな世界の実現に少しでも貢献するべく活動していきます。 Google 検索はどんどんパーソナライズが進んでいますが、それに伴ってプライバシーへの懸念も大きくなっています。検索キーワードはそれ自身がプライベートな情報ですし、履歴やスターの情報なども含めれば、漏れた時のダメージは Amazon おすすめ商品の比ではありません（笑）。 そのような状況に対応するため、 Google が試験的に SSL で暗号化された Goog
The purpose of this document is to summarize security issue CVE-2009-3555 (a man-in-the-middle vulnerability in the TLS/SSL protocol) which applies to SSL/TLS/https/etc., to describe what action has been taken in Mozilla, and to describe what action other parties should take. Background In 2009, a flaw was discovered in the SSL/TLS protocol which is widely used in Internet applications, for exampl
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 少し前にウェブブラウザがHTTPS通信する際のCipherSuiteを調べてみようと思って表を作ってありました。今日、ちょっと時間があったので対象ブラウザを新しいものにして表を更新したので、公開しようと思います。 以下のブラウザについて調べています。 Microsoft Internet Explorer 8.0 / Windows XP SP3 Microsoft Internet Explorer 7.0 / Windows Vista Firefox 3.6 / Windows XP SP3 Firefox 3.6 / Windows Vista Opera 10.10 / Windows XP SP3 Opera 10.10 / Wi
はてブiPhoneアプリでログインしてはいけない を読んで。 もしかしたら開発者じゃない人には UIWebView の事ってあんまり知られてないんじゃないかなあと思ったので書いてみます。 PCとかのソフトでもそうなんでしょうけど、野良ブラウザアプリを使ってる場合は、いま見てるページが本物かどうかを見分ける方法は無いです。 iPhoneアプリの中には URL を入力してウェブページを表示するいわゆるブラウザアプリが多くありますが、ブラウザアプリに限らず、ウェブページを表示する場合は UIWebView というUIコンポーネントを利用してまして、Safari と同じような表示が簡単に出来ます。この UIWebView には単にHTMLページを表示するだけの機能しかなく、表示中のページの URL を画面に表示する機能は存在しません。 なもんで、アプリ内にアドレスバーっぽいものが出てても、それが本
At last. What started as an "I need an overview of best practise in SSL/TLS configuration" type of idea, ended in a 3 month code, reverse engineer and writing effort. I really hope this comes in handy for you and was worth the effort. This is the "Release candidate" version of the paper, should no errors be found it will be the final version. What SSL/TLS configuration is state of the art and cons
First of all, here's the root certificate to be used for testing - import this into your client (at least temporarily) to get rid of warnings about an unknown certificate issuer. Unfortunately, your client [Hatena::Crawler/0.01] did not send a TLS server name indication extension (RFC 4366) in its ClientHello (negotiated protocol: TLSv1), so you're probably getting warnings about certificate name
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 Black Hat USA 2009でDan Kaminskyがタイトルはよくわかんないんだけど、SSLサーバー証明書関連で講演してちょっと話題になっているそうだ。 最初読んだときは(MD2やMD5の証明書の問題とからめて本人も混乱してるんじゃん？と思うような記事を書いちゃうひとに騙されて)攻撃方法がよくわかんなかったので、釈然としないままでいたんだけど、わかった〜〜〜と思ってブログに書こうかなぁと思いつつも、忙しくて時間がとれなくて、もうFireFoxから修正(3.5.2)が出ていた。 今流れている文章も誰のどこが悪いのか歯切れの悪い文章が多いために、すっきりしないので、ちょっと整理しようと思う。 NULL証明書攻撃 SSLサーバー証明書は
DoCoMoのこの夏モデルから、iモードブラウザ2.0というより高機能なiモードブラウザが搭載されるようになりました。 CookieやCSS,JSなど、大きな違いがありますので、実際に実機で確認をしてみます。 端末は、N-06A を使用します。なんか、発売停止なんてなってますが。。 Cookie まずは、Cookieについて。 以前、以下のような調査をしたことがあったので、同じ調査をしてみました。 auのSSLでのCookieの挙動がおかしい - maru.cc@はてな au,SoftBankでSSLでCookieセッションを使用する場合の問題点 - maru.cc@はてな 結果は、問題なく使えます。http<->httpsでの動作、secure属性の挙動も問題ありません。 これを使えば、Cookieセッションでセキュアなサイトがちゃんと作れそうです。 setcookie()の httpo
■ [Security] 40ビット暗号の攻撃可能性 SSL の話がだいぶあちこちで話題になっているようで、例えば もりぶさんの日記 などでもこんな疑問が出ている。 Firefox 1.0.6やSeaMonkeyで接続すると「低程度な暗号化を使ったページを要求しています」という警告出るんだけれど、これは安全なのでしょうか？ 特に問題無いならどうでもいい話ですが。 というわけで、果たして現実に40ビット暗号はどれくらい攻撃可能なのか？ というのを 検証してみようというのが今日のお題。今回は SSL2 の 40bit RC4 暗号化をターゲットにする。 まず、SSL2.0 の 40ビット RC4 暗号化での暗号鍵の作り方をざっとおさらいしておくと、 クライアントが 88ビットの乱数を平文で 40ビットの乱数をRSA暗号化して サーバに送信 サーバとクライアントはそれぞれ、それらを結合した128
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
