お約束

この発表は個人的な物で

仕事や所属等は全然関係ありません。

誤記や間違い等あればご指摘頂けると

助かります。
@takatayoshitake

自己紹介

@takatayoshitake

　広島を中心に勉強会に出没。
オープンソースカンファレンス広島の
お手伝いやいろんな勉強会でUstとか

やってます。(多分今日もやってる予定)

　広島サーバユーザ友の会(仮称)や
日本CloudStackユーザ会 広島支部等も

一応やってるみたい。

・・・何もできてませんが(汗

OSC広島の公式キャラクター
「あきちゃん」

http://j.mp/osc14hiaki

広島IT勉強会カレンダー(仮)の更新もしてます。

http://j.mp/hiitcal2

発表に入る前に

会場のみなさんに質問

WebサイトをHTTPSに

A. 既に対応している

B. 未だ対応していない

全員HTTPS対応済みだったら

終了

一人でも対応した事が無い方が居られたら続ける

WEBサイトをHTTPS

対応にする方法

今回の発表に至った経緯

HTTPS ページが優先的に

インデックスに登録されるようになります

Posted: 2015年12月18日金曜日

Google では常にユーザーのセキュリティを最優先に考え、長年にわたってウェブの安全性の向上やブラウジング体験の改善に取り組んできました。Gmail、Google 検索、YouTube では以前からセキュアな接続を実現しており、昨年は、検索結果での HTTPS URL の掲載順位を若干引き上げる取り組みにも着手しました。ウェブのブラウジングはウェブサイトとユーザーとの間の私的な体験となるべきであり、傍受、中間者攻撃、データ改ざんの対象となってはいけません。Google が「HTTPS everywhere」の推進に取り組んできたのはこのためです。

http://googlewebmastercentral-ja.blogspot.jp/2015/12/indexing-https-pages-by-default.html

今日の内容

1. HTTPS対応にする目的
2. 暗号化／通信のしくみ
3. 証明書の種類
4. サーバ証明書の取得と設定
5. まとめ

HTTPS対応にする目的

1. 通信のセキュリティ強化
2. Webサイトの信頼性証明
3. SEO対策

※今回 3 のお話はありません

通信のセキュリティ強化

WEB

サイト

パソコン

無線

ルータ

スマホ

タブレット

LAN

Wifi

・盗聴
 通信内容を覗かれる
・改ざん
 通信内容を変更される

Webサイトの信頼性証明

正規の

WEBサイト

パソコン等

例) SPAMメールや

標的型メール等により

ニセのWEBサイトに

誘導される

ニセの

WEBサイト

通信の暗号化

・暗号化
　通信の内容が当事者以外には解読できないように、

　文字や記号を“一定の約束”でほかの記号に置き換えること

・復号化
　暗号化されたデータを元に戻し、読める状態に戻すこと

暗号化／復号化の例

・元データ 123456 鍵 789

・暗号化
123456 × 789 = 97406784
元データに鍵を掛けて暗号データに変換

・復号化
97406784 ／ 789 = 123456
暗号データを鍵で割って元データに変換

※実際に使われている暗号化はもっと複雑です

共通鍵暗号方式の問題点

・暗号化と復号化で同じ鍵を使う方式を共通鍵暗号方式と呼びます
・共通鍵暗号方式では通信を行う相手毎に鍵を用意する必要があります
・共通鍵を通信で送った場合、共通鍵を盗聴されると暗号化通信も復号化される
・複数の通信先とどうやって安全に鍵を交換するかが課題

公開鍵暗号

・暗号化と復号に別個の鍵(手順)を使い、暗号化の為の鍵を公開できるようにした暗号方式

・公開鍵は全世界に公開
・秘密鍵は秘密裏に保管(自分だけが知っている)

・公開鍵で暗号化したデータは秘密鍵で復号化出来る
・秘密鍵を持っている受信者のみがデータを復号化できる

デジタル署名

・秘密鍵で暗号化したデータは公開鍵で復号化出来る
・秘密鍵を持っている送信者が発信したデータで有ることを確認出来る
・メッセージの完全性と作成者の認証が可能になる
→デジタル署名

公開鍵暗号方式やデジタル署名の詳細を説明するとそれだけでかなり時間がかかるので今回は割愛

とりあえず公開鍵と秘密鍵が必要なことだけ覚えておけば良いと思います。
 

※公開鍵暗号は共通鍵暗号よりも複雑なため暗号化、復号に時間がかかります。データの暗号化には「その場限りの共通鍵」を使用し、共通鍵を安全に交換するために公開鍵暗号が利用されています。

興味のある方は wikipedia/公開鍵暗号 等をご参照ください

j.mp/publickeycrypto

暗号化通信開始までの流れ

WEB

サーバ

WEB

ブラウザ

https:// でアクセス

暗号化仕様交渉

サーバ証明書送付

共通鍵生成

暗号化データ通信開始

サーバ証明書の検証

・サーバ証明書を受信したWebブラウザは正しいことを確認(検証)します。
・Webブラウザにはサーバ証明書を検証するために、あらかじめ信頼されたルート証明書が保存されています。
※正確には中間証明書もあわせて必要になります。

・証明書は公開鍵暗号を使用しており、作成するだけなら誰でも可能(自己証明書)
・ただしWebブラウザでサーバ証明書の検証するためにはルート証明機関に認証された認証局に証明書の発行を依頼する必要があります。

Webブラウザのルート証明書

Chromeの場合
 設定 - 詳細設定を表示

  - HTTPS/SSL

   - 証明書の管理
    信頼されたルート

　  証明機関

google.com の証明書

Webブラウザの鍵マーク

- 接続 - 証明書情報
 - 証明のパス

証明書の種類と選び方

証明書は色々な所で様々な金額で販売されています。
どんな種類があって何を基準に選べば良い？

証明書の呼び方

SSLサーバ証明書
SSL/TLSサーバ証明書
サーバ証明書

認証局等により呼び方が微妙に違いますが同じ物

SSL/TLS

・SSLSecure Sockets Layer）
・TLS（Transport Layer Security）
・共にインターネット上でデータを暗号化して送受信できる通信方式でHTTPS通信等で利用します。
・SSL3.0プロトコルを元に新たに作られたのがTLS。
・SSLはセキュリティの懸念から利用は非推奨とされておりTLSが多く使われるようになってきています。

※古い携帯電話やWindows XPのIE6等の古いWebブラウザはTLSに対応していないためSSL3.0を利用しているサイトも残っています。

認証レベル

・ドメイン認証 / Domain Validated (DV)
  ドメイン名の使用権のみを認証
  ドメインさえあれば個人でも取得可

・企業認証 / Organization Validation (OV)
  ドメインの使用権の認証に加え、申請した組織の実在性を認証

・EV認証 / Extended Validation (EV)
  登記簿謄本等や第三者期間のデータベース等により法的・物理的に組織の実在性を確認

主な利用用途

・ドメイン認証 / Domain Validated (DV)
 特定利用者のみアクセスするWebサイトへのセキュアなアクセス用

・企業認証 / Organization Validation (OV)
 企業のECサイトや個人情報等を入力するWebサイトで広く利用されている一般的な証明書。

・EV認証 / Extended Validation (EV)

 緑のアドレスバー表示により安全性をわかりやすくアピールしやすい
 銀行や大手企業のECサイト等金銭や重要な情報を取り扱うWebサイトで導入が進んでいる証明書

申請期間と費用

・ドメイン認証 / Domain Validated (DV)
 オンラインで数分～数時間で発行

 費用 数千円～

 ※サービスのオプションとして無料提供等もあり

・企業認証 / Organization Validation (OV)
 通常企業の実在確認に書類の郵送等が必要なため数日～

 電話確認のみの場合もあり

費用 数万円～

・EV認証 / Extended Validation (EV)

 企業の実在確認に追加して厳格な審査が必要なため最短10日，2～3週間程度

 費用 10万円以上

オプション

・ワイルドカード
 一つの証明書で複数のサブドメインに対応
  www.example.com
  www2.example.com
  www3.example.com
 ※ロードバランサ等Webサーバの前段の装置にインストールする場合もあり
・マルチドメイン
 一つの証明書で複数のドメインに対応
  www.example.com
  www.example.org

IPアドレスと拡張機能

・IPアドレスベース
 1台のサーバ(グローバルIPアドレス)につきSSL証明書は1ドメイン

・SNI(Server Name Indication)

 1台のサーバ(グローバルIPアドレス)で異なる証明書を使い分けることができる
 名前ベースバーチャルホストで必要な機能
 ※対応ブラウザが必要(IE7～,Opera 8以降～)

    注: Android 2.x のブラウザには非対応

対応ブラウザ wikipedia Server Name Indication

https://ja.wikipedia.org/wiki/Server_Name_Indication

共有ホスティングは要注意

・1台のサーバで複数のユーザを収容している共有ホスティングサービスについては様々な制約があります。
・技術的な問題だけではなく、コントロールパネル等での設定メニューの有無やサービス提供元のポリシーによっても異なります。
・導入前にサポートに確認しましょう

共有SSL

・ホスティングサーバやサービスによってはサービス提供会社が無料で提供する証明書を利用出来る場合があります。
・ただし独自ドメインが使えないためドメインや企業の実在証明が出来ない等のデメリットもあり

同じ種類の証明書で

値段が違うのは何故?

・各認証局の運用体制、創業時期、ブランドによるもの
・認証局のサービス開始時期等により古い携帯電話等ではルート証明書が入っていない場合もあり
・クライアントがパソコン以外の組込機器等を利用する事が解っている場合はルート証明書をあらかじめ確認
※スマートフォンの普及等によるブラウザの自動更新等で解消されつつある
・認証局によっては運用体制に問題がありセキュリティ事故等で取り消しとなった例も過去にあり
・一概に高ければ良いと言うものでは無いと思いますが、ある程度知名度のあるサービスを推奨

各携帯電話のルート証明書

docomo SSL機能の主なスペックについて

https://www.nttdocomo.co.jp/service/developer/make/content/ssl/spec/

au EZweb向けのWebコンテンツ作成にあったてのポイント

および注意点 - SSL証明書一覧

http://www.au.kddi.com/ezfactory/web/

SoftBank 3G 開発者向けサイト 技術資料 SSL証明書一覧

http://creation.mb.softbank.jp/mc/tech/tech_web/web_docandtools.html

HTTPS対応までの流れ

1. サービス内容、対象、目的を整理し何を守るか整理する

2. 証明書サービスの選択

3. 必要な書類等の準備(企業認証、EV認証)

4. CSRの作成

5. 証明書発行依頼

6. 証明書発行依頼確認、証明書受領

7. サーバへの設定

8. サービス確認、セキュリティ対応等

1. サービス対象や目的を整理し何を守るか決める

・お金の取引の有無、個人情報の取り扱いの有無や重要性の確認
・サポート対象のWebブラウザや携帯電話の有無等を整理
  ※セキュリティの問題等もあり古いブラウザや携帯電話等は
    対象外にする事もあり
・利用者が社内のみ等の特定の場合は自己証明や他のセキュリティ対策(VPN等)の利用もあり
・企業の実在証明の有無、より厳格な証明が必要か決める
  ※これにより費用が大きく異なる

・企業であればセキュリティ部門への報告等の社内手続き

2. 証明書サービスの選択

・Webサービスの内容や予算に応じて証明書サービスを選択

・ホスティングサービスやクラウドサービスを利用している場合は同じ会社のサービスや推奨サービスを利用する案もあり

・会社によっては証明書設定の代行サービス等もありサーバ設定に慣れていない場合は利用する手もあり

3. 必要な書類等の準備(企業認証、EV認証)

・企業認証、EV認証の場合は登記簿謄本や印鑑証明等が必要になる場合があります。
・WHOISデータベースに掲載されているドメイン名の所有名義が、申請企業/団体名と完全一致する場合で帝国データバンク、DUNSナンバー、職員録に基本情報が登録されている申請組織や公共団体の場合は、登記事項証明書が不要な場合もあり

各証明書サービス毎に異なるのでお問合せ下さい

4. CSRの作成

・CSRとは?
認証局に提出する署名リクエスト(Certificate Signing Request)

・Webサーバ上で秘密鍵を生成しCSRを作成

・証明書サービスによってはWeb上の管理画面で秘密鍵とCSRを作製出来る場合もあり

※証明書サービスのサポートページ等に一般的な作成手順が　公開されています。

例) Apache + OpenSSL

・秘密鍵の作成
openssl genrsa (暗号方式) -out (秘密鍵ファイル名) (キー長)

例）暗号方式「aes256」を用いてキー長「2048bit」の秘密鍵ファイル「example.key」を作成
openssl genrsa -aes256 -out example.key 2048
パスフレーズを2回入力

注: ここで入力したパスフレーズは忘れないように記録

      秘密鍵はサーバ故障等に備えて別の場所にコピーし保管

・作成した秘密鍵ファイルからCSR を作成
openssl req -new -key (秘密鍵ファイル名) -out (CSRファイル名)

例）秘密鍵ファイル「example.key」からCSR「example.csr」を作成
openssl req -new -key example.key -out example.csr

CSR作成時の入力項目

【Country (国名)】
  Country Name (2 letter code) [AU]: JP  
【State(都道府県名)】
  State or Province Name (full name) []: Hiroshima
【Locality(市区町村名)】
  Locality Name (eg, city) []: Hiroshima
【Organizational Name(組織名)】
  Organization Name (eg, company) []: hiroshima-server-user-group
【Organizational Unit(部門名)】
  Organizational Unit Name (eg, section) []: server

【Common Name(コモンネーム)】
  Common Name (eg, YOUR name) []: www.example.com
【以降は入力不要】
Email Address []:     A challenge password []:     An optional company name []:

5. 証明書発行依頼

作成したCSRの内容を証明書サービスのWebフォーム等で申請

$ cat example.csr
-----BEGIN CERTIFICATE REQUEST-----
MIICzDCCAbQCAQAwgYYxCzAJBgNVBAYTAkpQMRIwEAYDVQQIDAlIaXJvc2hpbWEx
EjAQBgNVBAcMCUhpcm9zaGltYTEkMCIGA1UECgwbaGlyb3NoaW1hLXNlcnZlci11
(中略)
VwQ1l0kbW02cl6En6X3+sAwMONBR5hvEtuss6UKPZ8vMkF7ETW4qHOu4hUUAO6zP
B8SdJpKO8YTWG13XZvU17ukupG7C/2sBcOPb5o1suzhWLdNg10b7M1+NY3vKobJG
-----END CERTIFICATE REQUEST-----

※ BEGIN の行から ENDの行まで 1～17行 全て貼り付け
注 BEGIN の行と ENDの行を除外しない事

企業証明書やEV証明書の場合は必要に応じて資料送付、電話対応等

6. 証明書の発行依頼確認、証明書受領

証明書の発行依頼を行った後に証明局から正式なドメインの持ち主からの発行依頼か確認のため、下記等のメールアドレスに確認メールが届きます。

webmaster@example.com
postmaster@example.com
webmaster@www.example.com
postmaster@www.example.com

webmaster: Web管理者 , postmaster: メール管理者
RFC2142 一般的なサービス、役割、機能に対するメールボックス名
http://rfc-jp.nic.ad.jp/rfc-jp/RFC2142-JP.txt

メールが受信できない場合はWebサーバにファイルを置き

httpアクセスで確認する事も可能なサービスもあります。

（メールが使えない場合は申請前に確認しましょう)

7. サーバへの設定(１)

・証明書ファイルを作成
 証明書発行メール本文中にある証明書部分
(-----BEGIN CERTIFICATE-----)から(-----END CERTIFICATE-----)までをコピーし、テキストエディタに貼り付け、証明書ファイルとして保存
 例： example.crt

・中間証明書ファイルを作成
 証明書発行メール本文中にある中間証明書部分
(-----BEGIN CERTIFICATE-----)から(-----END CERTIFICATE-----)までをコピーし、テキストエディタに貼り付け、証明書ファイルとして保存
 例： example_ca.crt
 証明書サービスによっては中間証明書はWebより取得の場合もあり

7. サーバへの設定（2）

・パスフレーズなしの秘密鍵ファイルを作成
openssl rsa -in (秘密鍵ファイル名) -out (パスフレーズなしの秘密鍵)
例: openssl rsa -in example.key -out example_passoff.key

※パスフレーズありだと毎回起動時に入力が必要になるため

・各ファイルをサーバ上に配置
証明書
 /etc/pki/tls/certs/example.crt
秘密鍵(パスフレーズなし)
 /etc/pki/tls/private/example_passoff.key
中間証明書
 /etc/pki/tls/certs/example_ca.crt

7. サーバへの設定(3)

Apache の設定ファイルに各ファイルのパスを設定
SSL設定ファイル /etc/httpd/conf.d/ssl.conf
 SSLCertificateFile    証明書
 SSLCertificateKeyFile 秘密鍵(パスフレーズなし)
 SSLCACertificateFile  中間証明書

例:
SSLCertificateFile /etc/pki/tls/certs/example.crt
SSLCertificateKeyFile /etc/pki/tls/private/example_passoff.key
SSLCACertificateFile /etc/pki/tls/certs/example_ca.crt

設定ファイル文法チェック  apachectl -t
設定再読み込み                service httpd reload

8. サービス確認、セキュリティ対応

・Webブラウザで表示確認
https://www.example.com/

・SSLの確認サイト等で脆弱性チェック

SSL Checker | Symantec CryptoReport

https://cryptoreport.websecurity.symantec.com/checker/views/certCheck.jsp

SSL Server Test

https://www.ssllabs.com/ssltest/

「Do not show the results on the boards」をチェックしないと結果がWebで公開されるので注意

注: 自身が管理しているWebサーバ以外を勝手にチェックしない事

診断結果(好くない例)

対処方法(例)

Apacheの初期設定ではこのように脆弱性が多数検出されます
SSLに関する下記等を修正（/etc/httpd/conf.d/ssl.conf）

修正前 SSLProtocol all -SSLv2
修正後 SSLProtocol all -SSLv2 -SSLv3 +TLSv1.1 +TLSv1.2
※SSLProtocol SSLv2とSSLv3を無効化、TLSv1.1とTLSv1.2を追加

修正前 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
修正後(1行) SSLCipherSuite AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:!RC4:HIGH:!EXP:!IDEA:!SEED:!EDH:!aNULL:!eNULL
※RC4等の脆弱性のある古い暗号方式を無効化し新しい暗号方式を追加

追加 SSLHonorCipherOrder on
※暗号化のダウングレード防止

追加(1行) Header always set Strict-Transport-Security "max-age=315360000; includeSubDomains"
※HTTPではなく HTTPS で暗号化通信をする様に設定

診断結果(対処後)

Forward Secrecy 対応は Apacheのバージョンアップが必要

無料で取得可能な証明書

- StartSSL
・非商用に限り無料プランあり

http://www.startssl.com/

- Let’s Encrypt
・現在2015/12/13より「Public Beta」で誰でも利用可
・商用利用も可ですが正式サービス後を推奨

https://letsencrypt.org/

Let's Encrypt 総合ポータル(日本語)

https://letsencrypt.jp/

StartSSL

http://www.slideshare.net/yo.takata/20150502ltdd14startssl

StartSSLについては2015/05/02 LT駆動開発14で発表した下記を

参照下さい。（画面のデザインとか違ってたらすみません）

「Webの通信を暗号化で安全に！  無料ではじめるSSL証明書入門」

Let's Encrypt とは

Let's Encrypt は、認証局（CA）として「SSL/TLSサーバ証明書」を無料で発行するとともに、証明書の発行・インストール・更新のプロセスを自動化することにより、TLS や HTTPS（TLSプロトコルによって提供されるセキュアな接続の上でのHTTP通信）を普及させることを目的としているプロジェクトです。
非営利団体の ISRG（Internet Security Research Group）が運営しており、シスコ（Cisco Systems）、Akamai、電子フロンティア財団（Electronic Frontier Foundation）、モジラ財団（Mozilla Foundation）などの大手企業・団体が、ISRG のスポンサーとして Let's Encrypt を支援しています。
Let's Encrypt の「SSL/TLSサーバ証明書」は、独自ドメインの所有者であれば、誰でも簡単に、無料で取得することができ、商用サイトでの使用も可能です。

※商用サイトでの使用は、Let's Encrypt 公開ベータプログラム（Public Beta Program）の終了後をお勧めします。

クライアントインストール

・クライアントインストール
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

・動作確認(ヘルプ表示)
./letsencrypt-auto --help

証明書発行(例)

./letsencrypt-auto certonly \
--webroot \
-w <Webサーバのrootpath> \
-d <Webサーバのホスト名> \
-m <メールアドレス> \
--agree-tos

例)
./letsencrypt-auto certonly \
--webroot \
-w /var/www/example/public_html \
-d www.example.com \
-m webmaster@example.com \
--agree-tos

ファイル保存場所の

シンボリックリンク

/etc/letsencrypt/live/$domain
  privkey.pem   秘密鍵
  cert.pem      サーバ証明書(*1)
  chain.pem     中間証明書(*1)
  fullchain.pem サーバ証明書+中間証明書(*2)

*1 Apache 2.4.8 未満
*2 Apache 2.4.8 以上 , nginx

Apache 2.4.8 未満 の設定例

設定

/etc/httpd/conf.d/ssl.conf
 SSLCertificateKeyFile=/etc/letsencrypt/live/<ドメイン名>/privkey.pem
 SSLCertificateFile=/etc/letsencrypt/live/<ドメイン名>/cert.pem
 SSLCertificateChainFile=/etc/letsencrypt/live/<ドメイン名>/chain.pem
例
/etc/httpd/conf.d/ssl.conf
 SSLCertificateKeyFile=/etc/letsencrypt/live/www.example.com/privkey.pem
 SSLCertificateFile=/etc/letsencrypt/live/www.example.com/cert.pem
 SSLCertificateChainFile=/etc/letsencrypt/live/www.example.com/chain.pem

その他前述のセキュリティ設定

設定ファイル文法チェック apachectl -t
設定再読み込み   service httpd reload

参考 CloudFlare

 無料で簡単に使えるCDN(コンテンツ・デリバリー・ネットワーク)サービス
 コンテンツを複数地域の複数サーバーに配置し、ユーザーのリクエストに対して最適なサーバーからコンテンツを配布する負荷分散サービス
 無料プランを含む全てのユーザーに、無償でSSL(https)接続サービスを提供

※DNSサーバの変更が必要

CloudFlare one-click SSL

https://www.cloudflare.com/ssl/

参考 AWS Certificate Manager

2016/01/21

New - AWS Certificate Manager ? Deploy SSL/TLS-Based Apps on AWS

https://aws.amazon.com/jp/blogs/aws/new-aws-certificate-manager-deploy-ssltls-based-apps-on-aws/

AWSより新機能「AWS Certificate Manager」（ACM) が発表され、無料でサーバ証明書を発行し、CloudFront、ELBで利用する事が可能になりました。

※1/23現在 ELBは一部北米リージョンのみ対応、順次増加見込

無料証明書の問題

・無料証明書はドメイン認証(DV)のため企業の存在証明にはならない
・誰でも無料で取れるのでフィッシングサイト等を作成する側もドメインさえあれば誰でも容易に取得できる
  今後はHTTPS対応でも問題のあるサイトがこれまで以上に増える可能性がある
・ドメイン名はよく似た文字のドメイン名を取得されれば比較的騙されやすい
  1(数字)とl(エル)、2(数字)とz(ゼット)、6(数字)とb(ビー)、9(数字)とq(キュー)
  ※日本語ドメインとかもっと見分けがつかない

      「ー」(ハイフン)と「―」(長音)？

・xxx.co.jp 等の取得時に企業確認を行う属性型が有効?

まとめ

・証明書はWebサービスの対象ユーザ等の目的にあったものを選択しましょう。
・無料の証明書サービスも始まり導入のしきいは下がり誰でも比較的簡単に導入出来るようになったので挑戦してみよう！
・WEBサイトをHTTPSに対応し安全な世界に!

おしらせ

2016年2月6日(土) オープンセミナー2016@広島
テーマ 「みんなでつくろうモダンな開発環境」

http://osh-web.github.io/2016/