その｢s｣を付けるために〜はてなブログHTTPS化の軌跡〜 / Rejectcon 2018

by papix

Slide 1

Slide 1 text

その｢s｣を付けるために～はてなブログHTTPS化の軌跡～ by id:papix (@__papix__) 株式会社はてな

Slide 2

Slide 2 text

papix 株式会社はてなアプリケーションエンジニア (2017年2月～) ブログMediaチームサービスリード｢はてなブログ｣をつくっていますアカウント類はてな: id:papix Twitter: @__papix__ GitHub: papix CPAN: PAPIX ブログ: https://papix.hatena(blog.(com|jp)|diary.jp)/ 趣味はPerlと, (交通機関を利用した)旅行去年JGC修行(JAL)を完遂しました(年間53搭乗/40,573km) 来年はいよいよSFC修行(ANA)をします

Slide 3

Slide 3 text

もくじはてなブログとHTTPS化～ここまでの流れ～なぜHTTPSにするのか? はてなブログHTTPS化の難易度第1部: 激闘! Mixed Contents!! 第2部: 組み上げろ! 証明書自動発行システム!! まとめ

Slide 4

Slide 4 text

はてなブログとHTTPS化～ここまでの流れ～

Slide 5

Slide 5 text

はてなブログとHTTPS化～ここまでの流れ～ 2017年9月25日 ... 告知 http://staff.hatenablog.com/entry/2017/09/25/143000 2017年11月20日 ... 管理画面HTTPS化完了 (第1フェイズ) http://staff.hatenablog.com/entry/2017/11/20/175000 2018年2月22日 ... はてな提供ドメインブログのHTTPS化完了 (第2 フェイズ) http://staff.hatenablog.com/entry/2018/02/22/150000 2018年6月13日 ... 独自ドメインブログのHTTPS化完了 (第3フェイズ) http://staff.hatenablog.com/entry/2018/06/13/160000

Slide 6

Slide 6 text

今日話すこと第1部: 激闘! Mixed Contents!! 第1フェイズ～第2フェイズの出来事主にMixed Contents対応を中心に... 第2部: 組み上げろ! 証明書自動発行システム!! 第3フェイズの出来事 Let's Encryptを活用した証明書取得の仕組みについて

Slide 7

Slide 7 text

なぜHTTPSにするのか?

Slide 8

Slide 8 text

なぜHTTPS化が必要か http://staff.hatenablog.com/entry/2018/02/22/150000

Slide 9

Slide 9 text

なぜHTTPS化が必要かより安全にはてなブログを活用して頂くため｢はてなブログMedia｣という企業向けの展開も行っているためセキュリティ強化は重要 HTTPSが前提となる技術スタックの登場 Progressive Web Apps, Service Worker... HTTPS化推進の波様々な企業/団体がWebサイトのHTTPS化を推進している Let's Encryptもその流れの中で登場してきた Chromeでは, HTTPの場合に警告が出るようになっている

Slide 10

Slide 10 text

はてなブログHTTPS化の難易度

Slide 11

Slide 11 text

UGCサービス UGC = User Generated Content サービスの利用者がコンテンツを生み出すサービスブログの場合, サービスの利用者(はてなブロガー)が記事というコンテンツを"生み出す" はてなブログはUGCプラットフォームとして"自由度"が高い HTMLで自由にブログをデザイン出来る, ブログの記事の中にも自由にHTMLを記述出来る

Slide 12

Slide 12 text

マルチテナントユーザーごとにブログを開設できる更に, 1人で複数のブログを持てるブログは, デザインもCSS含めてかなり柔軟にアレンジ出来る加えて, 企業向けの｢はてなブログMedia｣も同じコードの上で動いている

Slide 13

Slide 13 text

他サービスとの連携公式で様々なサービスのコンテンツを埋め込める Twitter, ニコニコ動画, はてなブックマーク, Amazon, iTunes... 自社サービスとの連携もあるはてなスター, はてなブックマーク

Slide 14

Slide 14 text

Mixed Contents ユーザーが自由にHTMLを書ける = 様々なコンテンツを埋め込める/ 読み込める画像, 動画, iframe, JavaScript, CSS... HTTPSのブログでHTTPのコンテンツを読み込むと, Mixed Contentsが発生する

Slide 15

Slide 15 text

独自ドメインはてなブログが提供するドメインだけでなく, 任意のドメインでブログを開設できる正確に言えば, はてなブログが提供するドメインから, 任意のドメインに切り替えることができる独自ドメインについては, これまではHTTPS対応が難しかったユーザが発行した証明書を預かるのは難しい(出来れば避けたい) Let's Encryptによって独自ドメインのHTTPS化も目処が立ってきた

Slide 16

Slide 16 text

要するに... はてなブログはHTTPS化という観点で見ると｢数え役満｣状態 UGCサービスマルチテナント他サービスの連携 Mixed Contents 独自ドメイン日本でも屈指のHTTPS化難易度を誇るのではないか...?

Slide 17

Slide 17 text

第1部: 激闘! Mixed Contents!!

Slide 18

Slide 18 text

はじめに: Mixed Contentsとは? HTTPSのURLでウェブサイトを読み込んだ時に起こりうる読み込んだHTMLから, 更に読み込まれるコンテンツがHTTPで読み込まれる時に発生する HTTP接続は暗号化されていないので, 改竄されたり, 通信を盗聴される危険性があるウェブサイトを閲覧しているユーザーに注意を呼びかけるため, ブラウザ上に警告が表示される

Slide 19

Slide 19 text

Mixed Contentsを回避するには? やることはシンプル HTTPSのウェブサイトから読み込むコンテンツは, 全てHTTPS で読み込むようにするつまり, http://... で読み込んでいる所に s を足して, https://... にすれば良い

Slide 20

Slide 20 text

Mixed Contentsを回避するには? しかし, 単純に http://... を https://... に置換するだけではいけない当然ながら, そのコンテンツがHTTPSで配信されていなければ意味がない! 従って... 機械的に/自動的に解決するのは難しい(埋め込むことが出来るコンテンツの種類が増えれば増えるほど) コンテンツごとに作戦を建てて, 丁寧に取り組んでいく必要がある

Slide 21

Slide 21 text

第1フェイズ～第2フェイズの方針

Slide 22

Slide 22 text

方針まずは, はてなブログが公式に提供する機能で埋め込んだコンテンツによって, Mixed Contentsが発生しない状態を目指す(Mixed Contents対策) 写真(Fotolife/Google Photo), はてなブログで書いた過去記事, 他のはてなブログの記事の引用, Amazon, 楽天, YouTube, Twitter, Instagram, はてなブックマーク, ニコニコ動画, pixiv, iTunes, Evernote, ぐるなび/食べログ, Gist, Flickr, 絵, ミイル... 他にも, ユーザーが入力したはてな記法によって展開され, 埋め込まれるコンテンツも存在する

Slide 23

Slide 23 text

方針その後に, アプリケーションの改修を実施してHTTPSで利用可能になる状態を目指す(アプリケーション改修) HTTPSでページを表示出来るようにする HTTPSに対応したページにHTTPでアクセスした場合, HTTPS にリダイレクトするようにする HTTPSに対応したページへはHTTPSでリンクを貼るフォームの送信先をHTTPSに変更する

Slide 24

Slide 24 text

Mixed Contents対策 HTTPS化したときに起こりうるMixed Contentsに対して, 取りうる対策は以下のどれか: HTTPSで配信する HTTPSのリソースが使えるように改良する機能を撤廃する

Slide 25

Slide 25 text

HTTPSで配信する自社が提供するコンテンツであれば, HTTPSで配信するように修正することもできる部署間で調整して作業を依頼したり, 直接修正してPull Requestを送ったり... これで済むなら一番手っ取り早い

Slide 26

Slide 26 text

HTTPSのリソースが使えるように改良する他社のサービスが提供するコンテンツを埋め込む場合, そのサービスが提供するAPIを使って, 埋め込むための情報を取得していることが多い API側も昨今のHTTPS化の流れに乗って, HTTPSでリソースを提供してくれることが多い HTTP/HTTPSの両方でリソースのURLを示してくれていたり... 利用するAPIのバージョンを上げると, リソースのURLが HTTPSになることもあった

Slide 27

Slide 27 text

機能を撤廃する最終手段どうしてもHTTPでしか配信されていないものもある対応が難しい場合, 記事中での利用状況なども調査して, 機能そのものを撤廃することもあった例: ニコニコ動画のマイリスト埋め込み機能当時は動画とコミュニティしかHTTPSでの埋め込みに対応していなかった

Slide 28

Slide 28 text

絵文字事件果てしないMixed Contents対策の中でも, 特に思い出深いエピソード...

Slide 29

Slide 29 text

｢絵文字記法｣の発見

Slide 30

Slide 30 text

｢絵文字記法｣の発見

Slide 31

Slide 31 text

｢絵文字記法｣の発見古参スタッフですら知らなかった｢絵文字記法｣の存在に気づいた絵文字記法を使うと, 指定したコードに従って, 最終的に画像が埋め込まれるその画像がHTTPでしか配信されていなかった! 更に何故か, その絵文字の画像ははてな社内の他サービスが配信していた!!!

Slide 32

Slide 32 text

｢絵文字記法｣の対応そもそも, はてなブログで使っているコンテンツを, 他サービスが配信しているという状況が良くないそのサービスが万が一撤退することになった時, またてんやわんやすることになるこの機会に, 丁寧にはてなブログ側で配信するように手を加えた手間としてはそこまでかからなかったが, 延々と対応している中で唐突に作業対象が増えるのは精神的に参った...

Slide 33

Slide 33 text

アプリケーション改修これもまた, Mixed Contentsと同じく地道な作業が必要 HTTPS化が必要な(可能な)エンドポイントをリストアップして, 1つずつ対応していく

Slide 34

Slide 34 text

開発環境のHTTPS化まずは開発者の環境もHTTPS化しておきたい出来れば手元でもHTTPSで確認したい開発環境はHTTPで本番環境はHTTPSだと, 意図せぬMixed Contentsを埋め込んでしまうかもしれない... 今回は, Docker + Nginx + いわゆるオレオレ証明書で解決ちょうどHTTPS化の作業が始まる前に, 開発環境のDocker化を推進していたアプリケーションの前にNginxのコンテナを立てて, 開発環境もHTTP/HTTPSの両方に対応

Slide 35

Slide 35 text

テストの追加やリファクタリング当然, テストもHTTPS環境に準拠したものに書き換えていく平行して, リファクタリングした方が良さそうなポイントは積極的に手を入れていった特に, リダイレクト周りの処理は丁寧にテストを用意はてなブログに存在する様々なパターンを網羅してテストした例: HTTPSが有効なはてなブログに, HTTPでリクエストすると, HTTPSにリダイレクトする...

Slide 36

Slide 36 text

QA アプリケーションの改修が完了した後, リリース前にQAフェイズを用意したはてなには専属のQAチームはないので, カスタマーサポートを担当するサポート部に協力を依頼 "QAシート"を用意して, それに従って操作を試し, 結果をまとめてもらう

Slide 37

Slide 37 text

QAシートの用意

Slide 38

Slide 38 text

QAの成果幾つか考慮漏れだったポイントを発見できたサポート部とHTTPS化による成果を共有できた言うまでもなく, ユーザーからのお問い合わせに対しては, サポート部のメンバーが対応する HTTPS化によって, ブログの挙動がどのように変わるかを, QA を通じて共有することができた

Slide 39

Slide 39 text

リリース

Slide 40

Slide 40 text

リリースまずは社員向けにリリースして動作検証問題がなければ, 一般公開を進めていく GitHubのIssueに手順書を用意して, リリースにあたって必要な作業を全て列挙関係部署への連絡, リリース後の動作確認手順など...

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

リリース前述の通り, 2017年11月20日に管理画面のHTTPS化(第1フェイズ), 2018年2月22日にはてな提供ドメインブログのHTTPS化(第2フェイズ)が完遂リリース前後でデータロストやサービス停止などの問題もなく, 平和にリリース出来たそしていよいよ正念場, 独自ドメインブログのHTTPS化(第3フェイズ)へと足を踏み入れる...

Slide 44

Slide 44 text

第2部: 組み上げろ! 証明書自動発行システム!!

Slide 45

Slide 45 text

はじめに技術的詳細については, 一緒に実装を担当した id:aereal の｢Builderscon tokyo 2018｣における発表資料を参考にしてください｢ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ｣ https://speakerdeck.com/aereal/the‑construction‑of‑large‑ scale‑tls‑certificates‑management‑system‑with‑aws

Slide 46

Slide 46 text

前提はてなブログでは数万単位のブログが独自ドメインで配信されているそれらの証明書を取得し, 配信時に適切に利用する必要がある｢証明書発行｣についてはLet's Encryptの登場によって解決独自ドメインのための｢証明書取得｣と｢証明書配信｣を実装しなければならない

Slide 47

Slide 47 text

余談: Let's Encryptへの貢献 Let's Encryptは, Internet Security Research Group(ISRG)という非営利団体によって運営されているこのような仕組みを無料で提供するISRGに経緯を評し, 寄付も実施した http://developer.hatenastaff.com/entry/2018/06/04/14 0000 毎年, 継続して寄付の活動を続けていきます

Slide 48

Slide 48 text

証明書取得の技術選定 AWS Certificate Manager はてなブログはAWSで構築されているので, AWSのフルマネージドサービスで対応出来ないか検討 AWS Certificate Managerで取得した証明書は, ELBに紐づけて利用することが出来る結果としては, 今回のオーダー(数万単位のブログ)では用途に適さないことが判明し, 断念

Slide 49

Slide 49 text

証明書取得の技術選定自前実装こうなってくると, 自前で仕組みを作るしかなさそうという結論に至る証明書の取得だけでなく, 更新(Let's Encryptの証明書は3 ヶ月で有効期限が切れる)も考慮しないとけない Step Functionsを軸に, LambdaやDynamoDBなど, AWSのフルマネージドサービスをフル活用して実装することを計画 Lambdaで動かすコードは, 公式に対応されたGo言語を活用することに決定チームメイトの言語習熟度や, 社内においてMackerelなどでGoが使われていることも後押しとなった

Slide 50

Slide 50 text

証明書配信の技術選定 AWS Certificate Managerが利用出来れば取得だけでなく配信も担えたが, これは断念 SAN Subject Alternative Names, 1つの証明書で複数のドメインを紐付ける仕組み Let's EncryptでSANを使う場合, ACME challenge(証明書発行のための認証)は, 現時点ではdns‑01のみが利用可能 dns‑01の認証ではDNSの設定が必要であり, はてなブログではドメインのDNS設定は各ユーザーに委ねなければならないので, 自動化が困難また, そもそもとしてLet's EncryptのSANでは, 1つの証明書あたり100ドメインまでしか含めることができない結果としては, 証明書配信についても自前実装することを決意

Slide 51

Slide 51 text

証明書配信の技術選定はてなブログでは, ProxyとしてNginxを採用している(EC2上に構築し, 複数台のProxyが配置されている) Q. 取得した証明書を, 複数台のProxyに配信どのように配信する? 取得した全ての証明書を配信するのは厳しい万単位のブログの証明書を読み込むと, メモリ使用量が著しく増加する証明書の更新が行われる度に読み込み直す必要がある

Slide 52

Slide 52 text

証明書配信の技術選定最終的には, GMOペパボでの事例なども参考に, 証明書の動的読み込みシステムを構築した ngx_mrubyを利用して, リクエストがある度に証明書をロードする Nginxではmruby以外にLuaを動かすことも可能だが, チームメイトの言語習熟度を考慮してmrubyを採用した

Slide 53

Slide 53 text

プロトタイプ実装本格的に開発を始める前に, 2週間のプロトタイプ実装期間を用意したプロトタイプを実装することで, 見積もりの最適化(誤差を減らす)と技術的課題点の早期発見を狙える正式版(?)の実装においては, プロトタイプの知見を利用するが成果物はそのまま使わない ...ので, ｢ひとまず動くものを作る｣の精神で, 素直に実装を進めていくエンジニアは東京オフィス/京都オフィスで別れていたので, 東京オフィスに集まって実装

Slide 54

Slide 54 text

プロトタイプ実装プロトタイプ実装は, Mackerelの次世代TSDBでの知見を活用予めプロトタイプ実装することで, 見積もりの精度を高めることができた実際, 第3フェイズはプロトタイプ実装後の見積もりとに対してほぼ誤差なく終えることができた

Slide 55

Slide 55 text

ベンチマークプロトタイプを利用して, ベンチマークも実装した実際にLet's Encryptで取得した証明書を, Nginx + ngx_mruby で捌くことが出来るか? 結果としては, 後述するキャッシュの仕組みなども想定して実装していたため, 無事に捌き切ることができた

Slide 56

Slide 56 text

プロトタイプの成果実際に動作するものを一通り構築する中で, 事前にタスクを見積もった時に考慮が漏れていた点を発見できた正式版の開発に着手するにあたって, 良い｢お手本｣が出来た自分の場合, Go言語にそこまで慣れていなかったので, プロトタイプで書いたコードはとても良いお手本になったデプロイの仕組み, CIの仕組みなども構築でき, それを正式版に活かすことができた

Slide 57

Slide 57 text

実装第3フェイズは, 2つのフェイズに分けて作業を進めた第3フェイズα ... 証明書の取得/配信の仕組みを作る第3フェイズβ ... 構築した証明書の取得/配信の仕組みと, 既存のはてなブログを繋ぎこむ前述の通り, プロトタイプ実装の成果もあって, 第3フェイズαについては見積もりどおり終わった第3フェイズβについては, 予定よりも少し伸びてしまったとはいえ, 第3フェイズ開始前の予定から大きく後ろに伸びることはなかった

Slide 58

Slide 58 text

詳解

Slide 59

Slide 59 text

結果 2018年6月13日, 無事独自ドメインのHTTPS対応(第3フェイズ)をリリースできたこちらもまた, サービスの停止やデータロストといった大きな障害なくリリースすることが出来た

Slide 60

Slide 60 text

このようにしてHTTPS化は進んだのです!!!

Slide 61

Slide 61 text

まとめほぼ1年をかけて, はてなブログのHTTPS化を成し遂げることができたこれほどの規模で, 長期間のプロジェクトに携わったことはなかったので, 良い経験になった第3フェイズの中で, Go言語やAWSの各種フルマネージドサービスといった, 新しい知見を得ることができて良かったまた, それぞれのフェイズでサービスダウンやデータロストといった大規模な障害なくリリースを終えることが出来たのも自信になった様々な条件がある中で, それらを満たしつつ, サービスをHTTPSする良い実装が作れたと思う

Slide 62

Slide 62 text

ご清聴ありがとうございました!