ピクシブ株式会社で開発基盤チームとして働いている @catatsuy です。主にpixivの技術的な改善をしていますが、広告チームも兼任しているので広告周りの開発もしています。 今回pixivの常時HTTPS化を担当したのでやったことを紹介します。 pixivをHTTPS化した理由 現在のインターネット全体の流れとして常時HTTPS化が進んでいます。エドワード・スノーデン - Wikipediaが暴露したNSAの事件発覚や 公衆無線LANの利用拡大により、通信経路上でユーザーの個人情報を保護することがインターネット全体として非常に重要になってきました。Googleが行っている調査によると、HTTPSページの閲覧時間はウェブ全体の利用時間の3分の2にも及びます。 それだけではありません。ブラウザに新しく追加されるAPIや機能（HTTP2/WebRTC/ServiceWorkerなど）はHTT
インフラストラクチャー部長の星 (@kani_b) です。 2017年1月5日をもって、クックパッド における全ページで HTTPS が使われるようになりました。 完全 HTTPS 化をするにあたり、その理由や具体的な進め方について紹介します。 以前 SRE Tech Talks #2 にて一部発表した内容も含みますので、ご興味のある方はあわせてスライドもご覧ください。 完全 HTTPS 化に踏み切った理由 以前のクックパッドは、ログインや登録情報の参照など、いわゆる個人情報や認証情報を扱う箇所のみに HTTPS が使われていました。 このように「必要な箇所にのみ HTTPS を使う」構成は、ある程度歴史のある Web サービスにおいてよく使われている構成です。 この状態から、完全 HTTPS 化に踏み切った理由を説明します。 サービスをよりセキュアにするため HTTPS の利用を考えるに
エグゼクティブサマリ GoDaddy社の発行するドメイン認証SSL証明書に認証不備の脆弱性があり、予防的な処置として8850件の発行済証明書が失効された。これは同期間に発行された証明書の2%未満である。現在は脆弱性は解消されている。 概要 GoDaddy社は米国のホスティング（レンタルサーバー）やレジストラの大手で、認証局（CA）の事業も手がけています。 GoDaddyが発行するドメイン認証証明書の認証手続きに不備があったとして報告されています。 In a typical process, when a certificate authority, like GoDaddy, validates a domain name for an SSL certificate, they provide a random code to the customer and ask them to p
サマリDNSによる認証(DNS-01)でドメインを認証し、Let’s EncryptからSSL証明書を取得することができたので、メモとしてまとめます。クライアントはサードパーティ製のletsencrypt.shを使用します。DNSで認証するには、ドメインに認証専用のサブドメインを追加し、サブドメインに対してTXTレコードを設定できる必要があります。HTTPによる認証ではないため、Webサーバは必要ありません。このためHTTPによる認証と比較してとても簡単に証明書を取得できます。HTTPによる認証と手間なところ無料でDVのSSL証明書を取得できるLet’s Encryptが話題です。 Let’s Encryptで証明書の取得を行う場合、HTTPを使用してドメインを認証を方法(HTTP-01)が紹介されることが多いようです。 この方法でドメインを認証する仕組みは、ざっくり説明すると以下のとおり
1. ワークアラウンドが見つかった！ 先日 id:jovi0608:20131106 で書きました256バイト以上のSSL ClientHello で負荷分散装置のTLSハンドシェイクがハングアップする件ですが、ワークアラウンドが見つかりました。Re: ALPN concerns にてF5のエンジニアから、 「TLSハンドシェイクの4オクテット目が 0x01 だった場合、SSLv2 の ClientHello と誤解釈していたバグだった。ClientHelloが512バイト以上のサイズならこのバグの影響を受けない。」 との情報がメーリングリストに投稿されました。結構驚きです。 2. 不具合の原因は？ これ、下図の例(サイズが256バイトのTLS1.2 の ClientHello、 0x16 0x03 0x03 0x01 0x00 から始まるバイト列)を見てみるとわかりやすいでしょう。 4オ
弊社の新規事業でWebサービスを作っていて、セキュリティトレンドの常時SSLってやつをやってみようと思った。 世のWebサービスを見てみるとやっている所が何故かほとんどなく、mixiやニコニコなどの大手もやってないようだ。ニコニコのURLを試しにhttpsにしてみたら繋がらず、mixiはhttpにリダイレクトされる。 うちは新規だから最初からhttps化することで特にデメリットはないと判断、安いSSL証明書を買ってhttpをhttpsにリダイレクトするようにした。技術的な難所はまったくないので問題なく実装完了し、これで安心度がちょっと上がったと思っていたのだが…。 つづく。 続き。 弊サービスではユーザーがYouTubeなどの動画を貼り付ける機能が重要なのだが、テストしてみるとニコニコ動画の埋め込みが動作しなくなっていた。調べてみるとニコ動の埋め込みコードがhttpなせいで、さらに最近のブ
数年前、Webは全体的に暗号化されていませんでした。HTTPSはWebページの最も重要な部分だけのために確保されていました。暗号化が必要なのは大切なユーザデータだけで、Webページの公開される部分は暗号化せずに送ってもいいということで意見が一致していました。 しかし、 今は 状況 が 違います 。現在では、どんなWebトラフィックでも暗号化されていないのは良くないということが分かっているので、Webサイトを運営する誰もがコンテンツに関係なく強固なHTTPSを設定しなければなりません。 お恥ずかしい話ですが、私自身のWebサイトは2年近くも全くHTTPSをサポートしていませんでした ^(1) 。 Eric Mill の 今すぐ無料でHTTPSに切り替えよう という素晴らしい記事が最終的に私に喝を入れてくれました。私は休暇中、HTTPSをセットアップして Qualys SSL Report で
Lenovo製のPCの一部にSuperfishというマルウェアが標準でインストールされていることが確認され、大きな問題となっています。 [2015-11-24追記] DELL製のPCにも、「eDellRoot」とされるSuperfishと同様の問題を持つルート証明書が導入されているようです。 DellのPCに不審なルート証明書、LenovoのSuperfishと同じ問題か - ITmedia エンタープライズ Dude, You Got Dell’d: Publishing Your Privates - Blog - Duo Security Joe Nord personal blog: New Dell computer comes with a eDellRoot trusted root certificate https://t.co/chURwV7eNE eDellRootで
現在SSL証明書の署名アルゴリズムがSHA–1からSHA–2へと変更になる過渡期となっています。今後はSSL証明書の新規取得や更新を行う際にはSHA–2の証明書を取得することになると思いますが、いつも通りの慣れた作業と思っていると、思わぬところでハマるかも知れません。 今回は実際に更新作業をした経験を踏まえて取得/更新作業の注意点について簡単にまとめてみました。 そもそもなぜSHA–2に移行する必要があるのか？ 署名アルゴリズムがSHA–1の証明書は非推奨となり、ゆくゆくは廃止となる流れとなっています。基本的にSHA–1の証明書は2017年1月1日以降使えなくなると考えてよいでしょう。そして2016年12月31日までにSHA–2に移行する必要があります。 詳細はここで説明すると長くなりますので、次のようなSSL証明書の発行元のサイトの解説を参照してください。 SHA–1証明書の受付終了とS
表を見ていただければわかる通り、Microsoft WindowsのSHA1移行ポリシに比べて、Chromeはかなりアグレッシブな設定になっており、開発版は2014年9月26日のアップデートから、安定版は2014年11月頃リリースの39から正常なHTTPS接続でないかのようなステータス表示となってしまいます。 今回のChromeのSHA1対応ポリシの問題点 今回のGoogle ChromeのSHA1証明書に対する対応計画は様々な問題があると考えていて、論点を整理したいと思います。 最も重要だと思うのが、ブラウザ毎にHTTPSのエラーや問題に対する表示の意味が異なってしまうという点です。今回のSHA1証明書の表示の計画がブラウザベンダー毎に異なるのはユーザが混乱することになり、良くなかったと思います。本来ならCA Browser ForumのBaseline Profileなどで、業界で意思
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
こんにちは。 職人見習いの高嶋です。 SSLの設定をするにあたって、最近では当たり前のように耳にするようになった 『中間証明書』や『クロスルート設定用証明書』。 正直その意味や用途を理解もせず証明書発行企業の説明文そのままに設定していたので 今回少し掘り下げて調べてみました。 そもそも私自身に『中間証明書』や『クロスルート設定用証明書』なる単語に 馴染みを持っていないのは、昔はWebサーバ上にSSLの設定をする際に それらを必要としなかったからです。 証明書発行企業によって文言は異なるが、概ね下記のように2階層での有効性を 検証する形でした。 ルート証明書（ブラウザに標準搭載） ┗サーバ証明書（Webサーバに設定） ■Apacheでの設定例 SSLEngine on SSLCertificateKeyFile conf/hoge.jp.key # 秘密鍵 SSLCertificateFil
お申込み前の確認 証明書発行までの所要日数を教えてください。 他社（別組織）が所有しているドメイン名で申込みできますか？ サーバー証明書の発行日を指定できますか？ 電話でのお申込みの意思確認はどのように行いますか？ 必要書類の要否などを事前に知りたいです お手続きについて 証明書の申込み手続きとサーバーの設定方法について教えてください。 「発行通知 E-mail アドレス」の変更手続きについて 住所や社名変更予定がある場合は、どんな手続きをすべきですか？ 証明書を利用中の Web サーバーをリプレイス（交換）する際の手続きについて 申込みのキャンセル手続きについて ドメイン名使用権の確認について ドメイン名使用権確認メール内の承認範囲は、どれを選択すればいいですか？ ドメイン名使用権確認の承認範囲の違いと影響を教えてください。 ドメイン名使用権確認メールのサンプルや承認画面のサンプルはあり
読者の方々は、SSLは当然ご存じであると思う。ただ、1024bit証明書・2048bit証明書が存在し、どのように我々に影響を与えているかを、どこまでご存じだろうか。証明書の現状と、今抱えている危機について、紹介したい。 NICT(米国商務省国立標準技術研究所)が勧告した最初のガイドラインでは、RSA512であった。つまり、暗号化キーの長さが512bitである（RSA暗号は公開鍵暗号の一種。現在は他にECC暗号が利用されている）。 RSA512にはすでに脆弱性が発見されており、解読できることがわかっている。そのため早い段階で、キー長の標準は、1024bitになった。しかし、コンピュータ技術の進展によって、計算性能も向上し、1024bitですら解読できる可能性が高くなってきた。そこでNICTは、1024bitの暗号の利用期限を2010年末に決定し、2048bitへの移行を促した。これが暗号の
クロスルート（クロスサート）とは、あるルート証明書から発行されたサーバ証明書を別のルート証明書が設定されているブラウザでも利用できるようにする仕組みです。 弊社のEV SSLは、ルート証明書「GlobalSign Root CA - R2」から発行されておりますが、古いバージョンのブラウザには、このルートが搭載がされていないため、ルート証明書「GlobalSign Root CA」 からもチェーンできるようにしております。 弊社のEV SSLは、全ての階層を2048bitの鍵長で発行しております。2010年問題にも対応しておりますので安心してご利用ください。
SSLの認証局とか証明書とか勉強し始めはホント難いよね このへんのSSL/TLSの仕組みって勉強し始めの頃は凄く難しく感じるのよね。分かりやすく解説してくれてるサイトってあんま見たこと無いし。 んで、 >>300,304 みたいなことは僕も昔考えたことあったわー、と懐かしみを覚えたのでレスってみた。 証明書を発行できるかどうかは証明書のフラグで決まっている、という >>303 の指摘も重要よね。 以下2chスレより引用 丁寧過ぎると評判のレスをしてるID:UyEJo1f2が僕なわけだがｗ 2chだとそのうち倉庫に行っちゃうかもしれないのでここにメモ。 【認証局】SSLに関するスレ 2枚目【ぼろ儲け】 http://hayabusa6.2ch.net/test/read.cgi/mysv/1286532904/298-309 298 ：DNS未登録さん：2013/05/31(金) 13:31
,、,, ,、,, ,, ,, _,,;' '" '' ゛''" ゛' ';;,, （rヽ,;''"""''゛゛゛'';, ﾉｒ） ,;'゛ i ＿ 、＿ iヽ゛';, ,;'" ''| ヽ・〉 〈・ノ |ﾞ゛ `';, ,;'' "| ▼ |ﾞ゛ `';, ,;'' ヽ＿人＿ / ,;'_ ／ｼ、 ヽ⌒⌒ / ﾘ ＼ | "ｒ,, ｀"'''ﾞ´ ,,ﾐ゛ | | ﾘ、 ,ﾘ | | i ゛ｒ、ﾉ,,ｒ" i _| | ｀ー――----┴ ⌒´ ） （ヽ ＿＿＿＿＿＿ ,, ＿´） （_⌒ ＿＿＿＿＿＿ ,, ィ 丁 | | | 前回のエントリ で軽く触れましたが、ARPスプーフィングを用いると、サブネット内からデフォルトゲートウェイを通って外に出て行くはずのパケットを、自分のホ
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
