CloudFront SSL ＋ ELB SSL - Qiita
以前は ELB で負荷分散してたんだけど、そろそろ限界を感じてきたり、世界展開などを考えて CloudFront を CDN として導入したいようなケースは結構あるように思います。 以前の構成：クライアント <---- https ----> ELB <---- http ----> EC2 改善後の構成：クライアント <---- https ----> CloudFront <---- https ----> ELB <---- http ----> EC2 例えば元々 ELB に「www.domain.com」というドメインとその SSL 証明書が配置されていた場合、クライアントからのエンドポイントは変更出来ないので「www.domain.com」の向け先を CloudFront に変更する必要があります。 ただこのとき CloudFront のオリジンサーバーとして ELB を設定す
日本国内でのLINE利用を韓国当局が傍受することは困難 - 雑種路線でいこう
月刊FACTA7月号で、LINEが韓国の国家情報院に通信傍受されているとする記事が掲載された。これに対してLINEの森川亮社長が「国際基準を満たした最高レベルの暗号技術を使って通信されていますので、記事に書かれている傍受は実行上不可能です」と反論、さらにFACTAの阿部編集長が「それが破られているというのが本誌の認識」と再反論している。その後LINEはITMediaの取材に対し「暗号化後データは独自形式、解読は不可能」と回答した。 LINEの開発者向けブログによるとLINEはサーバーとの通信に通常TLS/SPDYを使っているが、3G通信などで遅延が大きい場合には利用者の操作性を優先して暗号化せずに通信を行う場合があると書かれている。データセンターは日本にあるとのことなので、FACTAの記事にある韓国政府のサイバーセキュリティ関係者の発言が仮に事実であったとして、少なくとも韓国国内での遅延の
AWS Solutions Architect ブログ
AWSのソリューションアーキテクトの荒木(twitter: @ar1)です。 Amazon EC2のElastic Load Balancing(ロードバランサ、以下、ELB)のSSLターミネート機能は非常にパワフルで、利用されているユーザも多いかと思います。今日は、その機能を安全に使い続けるためのELBのSSL証明書更新の方法をまとめておきます。 忙しい方向け ELBのSSL証明書更新について覚えておくことは次の３つです。 SSL証明書の更新はマネージメントコンソール、CLIかAPIで可能です。 基本セッション切れはありません。 古くなった証明書はAPIで削除します。 ELBを長年使っていると、SSL証明書の更新のタイミングを迎えることとなります。また、不幸にも更新をせざるを得ない事は起こりえます。そこで、ELBのSSLターミネート機能を使いはじめる前に知っておくことはだれにとっても有益
CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば
必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも) SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして
HTTP/2における明示的プロキシ(Explicit Trusted Proxy)について
先日Jxckさんがセッションオーナーを務めた次世代Webセッション@CROSS2014に参加してきました。 セッションではSPDYやHTTP/2(その当時はまだHTTP/2.0だったかな)について主にリソース転送をどうよくするかについて話がされ、QUICなど”Post-TCP”な話も出て非常に興味深く楽しみました。 そこで「僕が考える次世代Web」というお題でブログを書けとJxck先輩から宿題をいただいて、何の話を書こうかなとずーっと思っていたのですが、最近のIETFの議論で個人的にはとても大切だと考えるトピックがあったので紹介＋僕の思いを書きたいと思います。 [訂正] 私がドラフトを読み違えていたのが問題なのですが、このExplicit Proxyの仕組みはhttp schemeの場合だけ適用され、httpsでは適用されません。そのため、httpsについては引き続き安全だと言えます。 し
CloudFrontでhttpリクエストをhttpsにリダイレクトできるようになった | iret.media
アクセスしてみる こんな感じでhttpアクセスしてみると、 ↓↓↓ httpsにリダイレクトされてました。 今回はS3ホスティングで試しましたが、EC2でWebサイトをホスティングするときも同様です。うちでよく組む構成だと、EC2でWebサイトをホスティングする場合、CloudFrontでSSLをターミナーションして、EC2ではhttpのみで扱うことも多く、EC2側のApacheでhttpsにリダイレクトするような構成ができませんでしたが、この機能を有効にすればhttpでリクエストされても自動的にhttpsにリダイレクトされる構成ができるという点で有効かなと思いました。
CloudFrontのSSL/TLS対応 まとめ | DevelopersIO
それぞれ解説します。 1. 共用SSL証明書 最も手軽にSSLを利用する方法です。特に事前準備無く、手軽にCloudFrontでHTTPS通信ができるようになります。 2.独自SSL証明書(IPベースモード) こちらは昨年6月に追加された機能で、あらかじめユーザーでSSL証明書一式を準備しアップロードして利用するタイプです。具体的な手順は、以下のブログエントリーを参考にしてください。 CloudFrontの独自ドメインSSL証明書対応を試してみた ｜ Developers.IO ここではちょっと横道に逸れて、なぜ追加料金がかかるのかを考察してみます。 Webサーバーでは1台のサーバーで複数ドメインをホストするバーチャルホスト構成として、以下の2つの方式を利用します。 ネームベース サーバーは、クライアントからのHTTPリクエストヘッダに含まれるHOSTヘッダでどのドメイン宛かを判断します。
ELBでのhttps表示を激的に早くする〜mod_spdy〜 - サーバーワークスエンジニアブログ
お久しぶりです。 好きなAWSサービスは、「Elastic Stomach Cloud」のザビオです。 最近は社内教育の一貫でやたら強制的に大盛りを注文されてしまいます。 本当東京は怖いです。 江戸川橋は制覇したかと思いますので、他にありましたら教えてください。 さて本題ですが、皆様、mod_spdyをご存知ですか？ 知らない人のために下記ブログをみると分かるかもしれません！ mod_spdyを試してみた(Amazon linuxで) 簡単に言えば、https表示を早くするapacheのモジュールです。 ELB配下のインスタンスにmod_spdyをインストールしてhttps表示が早くなるか調べてみました。 環境図 一つのインスタンスにのみmod_spdyをインストールし、実際に速度改善されたか、表示速度を検証してみました。 インストール 両方のインストールにapache、mod_sslをイ
ELB で SSL 復号するときしないときのベンチマーク - Qiita
sudo yum install npm --enablerepo=epel npm install express cat <<EOT >index.js var app = require('express')(); app.get('/*', function(req, res) { if (req.query.wait) { setTimeout(function() { res.write('OK'); res.end(); }, req.query.wait); } else { res.write('OK'); res.end(); } console.log('%s %s %s', new Date(), req.method, req.url); }); app.listen(10080); EOT node index.js $ ab -n 5000 -c 200 ht
米Yahoo!、検索のSSL暗号化へ - yahoo.comからの来訪者を判別不能に ::SEM R (#SEMR)
米Yahoo!、検索のSSL暗号化へ - yahoo.comからの来訪者を判別不能に 米ヤフーもグーグルに続いて検索の暗号化実施。クリック先ページに一切の参照元データを渡さないため、マーケターは yahoo.com からの来訪者か判別することが不可能に。 公開日時：2014年01月23日 06:53 米Yahoo!がプライバシー保護を目的に、Google に続いて検索サービスのSSL暗号化を実施する。現時点で米国（yahoo.com）が対象。 米国政府によるインターネットデータの盗聴問題などを受け、米Yahoo!は自社サービス及びネットワーク上に流れるデータの第三者による傍受を阻止し、ユーザーのプライバシーを最優先で守るための方針を示していた。今回、その一貫として検索データを暗号化する。 検索の暗号化は Google が先行して既に実施済み。ただし米Yahoo!は、参照元データそのものをク
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
SSL証明書のインストールチェックはどのサイトを利用すべきか - このブログはURLが変更になりました
先日ツチノコブログでクロスルート証明書の確認にIE6を使ってる話が紹介されてた。 確かに実機で確認するのは大事なのだが、SSL証明書が正しくインストールされているかチェックしてくれるサービスがいくつかある。 それで確認すればいいんじゃね？と思って調べてみたが、実はクロスルート証明書まで調べてくれるサービスは少ない。また各社チェックしてくれる内容が結構違う。 そこでオススメのSSL証明書チェックサイトを3つ厳選してみた。 Qualys SSL Labs SSL Server Test クロスルートを含む複数のチェインを表示してくれるのは試した限りここだけだった。 また、クロスルート以外にも脆弱なプロトコルや暗号アルゴリズムを使用していないか、BEAST、CRIME、Lucky13、BREACHなどの攻撃に対して対策されているかなども調べてくれる。 グレード表記や項目別スコア表示もあり。最低限
見せてもらおうか、IntelのAES-NIの性能とやらを 〜OpenSSLでベンチしてみた〜 - ..たれろぐ..
AES-NI の乗ってるマシンが使えたので OpenSSL でベンチマークしてみた。 結果：AES-NI なし 80〜90MB/s AES-NI あり 500〜530MB/s 「通常の５倍のスピードで処理してます！」「圧倒的じゃないか、我が軍は」 アクセラレーション命令の効果ってすごいねｗ 環境 パッケージ openssl-1.0.0-20.el6_2.3.x86_64 OpenSSL 1.0.0-fips 29 Mar 2010 built on: Wed Mar 28 01:11:34 BST 2012 options:bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THRE
なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
Google先生の検索結果リンクが予想以上に作り込まれていた件 - Y's note
Index 検索結果のリンクは単なるRedirectorでは無かった 検索結果のhttps化 httpsからhttpページへの遷移ではブラウザはRefererを送らない Google先生はRerererを送る仕組みを実装してくれた Refererが送信される処理の流れを追う httpsからhttpsページへの遷移はどうなるか Google Analyticsで検索Queryが「not provided」となる本当の理由 まとめ 検索結果のリンクは単なるRedirectorでは無かった 知らなかったのが僕だけだったら凄い恥ずかしい内容なんですが、今までGoogle先生の検索結果として表示されるリンクのURLはGoogle内部でClick集計するためのRedirector機能だと思っていました。カウントアップの集計を記録したら本来のURLに遷移させるような。当然そのClick数を集計する機能も
AWS News Blog
Amazon SageMaker Geospatial Capabilities Now Generally Available with Security Updates and More Use Case Samples At AWS re:Invent 2022, we previewed Amazon SageMaker geospatial capabilities, allowing data scientists and machine learning (ML) engineers to build, train, and deploy ML models using geospatial data. Geospatial ML with Amazon SageMaker supports access to readily available geospatial dat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News
New community features for Google Chat and an update on Currents
How much of a performance hit for https vs http for apache?
SSL証明書比較 | takeHoのへなちょこ日記