SlideShare a Scribd company logo
メールサーバ勉強会 #mailerstudy 02
メールと暗号
- SSL/TLS -
株式会社ハートビーツ 滝澤 隆史
2




私は誰
• 氏名: 滝澤 隆史 @ttkzw
• 所属: 株式会社ハートビーツ
• 何やっている人
 ▫ メーラMuttの国際化や日本語対応パッチ作者
 ▫ SpamAssassinの日本語対応パッチ作者
• メールシステムとの関わり
 ▫ システム管理者として1997年から2006年までメールサー
   バの管理
 ▫ 昔、qmail関連で色々やっていた。2006年にqmail捨て捨
   て。Postfix/Dovecot遣いにクラスチェンジ
 ▫ 現在は個人サーバでメールサーバを運用
   Postfix + Dovecot + Sieve(dovecot-pigeonhole) +
    ClamAV + SpamAssassin + spamass-milter +
    Roundcube
アジェンダ
• SSL/TLS
参考図書
• マスタリングTCP/IP SSL/TLS編
 ▫ 著者: Eric Rescorla
 ▫ 出版社: オーム社
• 新版 暗号技術入門 秘密の国のアリス
 ▫ 著者: 結城 浩
 ▫ 出版社:ソフトバンククリエイティブ
• RFC
• WikiPedia
#mailerstudy 02 メールと暗号 - SSL/TLS -
SSL/TLSとは
• インターネット上の安全な通信を提供するプロ
  トコル
 ▫ 機密性(暗号化)
   通信内容が漏洩しないこと
 ▫ 完全性
   通信内容が改ざんされないこと
 ▫ 認証
   通信相手が本人であること
SSL/TLSとは
• 透過性
 ▫ TCPの通信を囲うトンネルのような役割
 ▫ HTTP以外にも利用できる
   SMTP, POP3, IMAP, LDAP, .....
SSL/TLSとは
• SSL
 ▫ Secure Socket Layerの略
• TLS
 ▫ Transport Layer Securityの略
SSL/TLSの歴史
• SSL 1.0
 ▫ ネットスケープコミュニケーションズ社により開発
 ▫ 設計中に問題が見つかりリリースされなかった。
• SSL 2.0
 ▫ 1994年発表
 ▫ 最初に実装されたバージョン
    Netscape Navigator 1.1
 ▫ 様々なセキュリティ上の問題が見つかっている。
• SSL 3.0
 ▫ 1995年発表
    Netscape Navigator 2.0
 ▫ 今でも使われている。
SSL/TLSの歴史
• TLS 1.0
 ▫ SSL 3.0のベースにして、 IETFによりインター
   ネット標準として開発された。
 ▫ 1999年、RFC 2246 "The TLS Protocol Version
   1.0"が公開
 ▫ よく使われている。
 ▫ CBC攻撃のリスク
SSL/TLSの歴史
• TLS 1.1
 ▫ 2006年、RFC 4346 "The Transport Layer
   Security (TLS) Protocol Version 1.1"が公開
 ▫ CBC攻撃に対する耐性の強化
 ▫ 実装があまり進んでいない。
• TLS 1.2
 ▫ 2008年、RFC 5246 " The Transport Layer
   Security (TLS) Protocol Version 1.2"が公開
 ▫ SHA-256のサポート
 ▫ 実装があまり進んでいない。
SSL/TLSのバージョンのまとめ
• SSL 2.0
 ▫ ダウングレード攻撃の影響を受けるため、無効にしな
   いといけない。
• SSL 3.0, TLS 1.0
 ▫ よく使われている。
 ▫ CBC攻撃のリスク有り
• TLS 1.1, TLS 1.2
 ▫ TLS 1.1以降の利用が望ましい
 ▫ 実装が進んでいない
      OpenSSL 1.0.1以降で対応
      IE 8, IE 9(Windows 7, Windows 2008 R2)は対応
      Opera 10は対応
      Firefox, Chrome, Safariは非対応
#mailerstudy 02 メールと暗号 - SSL/TLS -
TLSプロトコル
                             暗号パラメータ      アプリケーション
暗号スペックの                                  データをTLSレコー
                   アラートの通知   や乱数や公開鍵
 変更の通知                                   ドプロトコルに渡す
                               の交換

ChangeCipherSpec     Alert   Handshake
   プロトコル            プロトコル    プロトコル       アプリケーション
                                            データ
                                           プロトコル
            TLSハンドシェイク プロトコル


                     TLSレコード プロトコル



・上位プロトコルから受け取ったデータを暗号化してTLSレコードにする。
・受け取ったTLSレコードを復号したデータを上位プロトコルに渡す。
TLSレコード
• TLSにおいて実際に暗号化されたデータとその
  ヘッダ
                ヘッダ             暗号文


          コンテント プロトコル
                      データ長
           タイプ  バージョン



上位のプロトコルタイプ           SSL 3.0→3.0
・change_cipher_spec   TLS 1.0→3.1
・alert                TLS 1.1→3.2
・handshake            TLS 1.2→3.3
・application_data     歴史的経緯↑
TLSレコード                      上位層から渡されたデータ

ブロックデータを214             ブロックデータ(平文)
(16384)バイト以下に分
割する。

                     フラグメント           フラグメント
フラグメントを圧縮する。
                                    MACシークレットを共
                     圧縮
             ヘッダ
                   フラグメント
                             MAC値   通鍵として、シーケン
圧縮フラグメント
                                    ス番号とヘッダと圧縮
とMAC値を共通鍵
                                    フラグメントからMAC
で暗号化する。
                                    値を計算する。
             ヘッダ      暗号文

 暗号化により                             MAC値により完全性
機密性が保たれる。                           の検証とメッセージ
                   TLSレコード          認証を行う。
TLSレコードが実現するもの
• 暗号化
 ▫ 機密性
• メッセージ認証コード(MAC)
 ▫ 完全性(改ざんされていないことの確認)
 ▫ メッセージ認証
TLSレコードだけでは
実現できないもの
•   共通鍵の交換(鍵配送問題)
•   公開鍵証明書の検証
•   利用する暗号スイートの合意
•   →ハンドシェイクで行う
TLS通信の流れ
• 次の段階に分けられる
▫ ハンドシェイク
▫ アプリケーション データ
▫ コネクションの終了
• 通信の流れを見てみよう
▫ ただし、
  サーバ認証
  RSA認証
▫ の場合についてのみ説明
通信の流れ
クライアント                        サーバ
             ClientHello
                                    利用する暗号スイートを
            ServerHello             決めたり、鍵を生成する
             Certificate            ための乱数や証明書のや
          ServerHelloDone           りとりを行う。
          ClientKeyExchange         ハンドシェイク
          ChangeCipherSpec
                Finished
          ChangeCipherSpec          暗号化したデータのやり
              Finished              とりを行う。

         アプリケーション データ
                                    アプリケーション
                                    データ

             close_notify
                                    終了
Helloメッセージ
クライアント                  サーバ
          ClientHello
    ・プロトコル バージョン
    ・クライアントが生成した乱数
    ・セッションID
    ・利用できる暗号スイートのリスト          クライアントとサーバ間
    ・圧縮方法                     で互いに利用可能なセ
                              キュリティ情報の交換を
         ServerHello          行う。
    ・プロトコル バージョン
    ・サーバが生成した乱数
    ・セッションID
    ・利用する暗号スイート
    ・圧縮方法
Helloメッセージ
クライアント                     サーバ

           Certificate

    ・公開鍵証明書のチェイン
     ・サーバの証明書
     ・中間CAの証明書
     ・ルートCAの証明書
       クライアントがすでに持って
       いることを前提に省略可
                                 クライアントは
         ServerHelloDone         ServerHelloDoneを受
                                 け取った後に、サーバの
    ServerHelloの終了を知らせる。
                                 証明書の検証を行う。
復習)公開鍵基盤(PKI)                      ルート認証局

              OSやソフトウェアに
               バンドルして配布       ルート証明書

アリス
          ルート証明書
              公開鍵
                                       中間認証局
        署名の
        検証                    中間証明書

              署名
証明書パス     中間証明書
 の検証          公開鍵
                                         ボブ
        署名の
                              中間証明書
        検証
              署名
  ボブの     ボブの証明書
  公開鍵                         ボブの証明書
              公開鍵
                      一緒に配布
                      ボブが配布
プレ マスター シークレットの送信
クライアント                         サーバ

         ClientKeyExchange           クライアントは公開鍵で
                                     暗号化して送り、サーバ
    ・公開鍵で暗号化された
                                     はプライベート鍵で復号
     プレ マスター シークレット
                                     する。
                                     安全にプレ マスター シー
                                     クレットを送信できる。

                             マスター シークレット
                             を生成するのに利用する
                             クライアントで生成した
                             乱数
マスター シークレット
  クライアント   プレ マスター     サーバの
   の乱数     シークレット       乱数



            マスター        鍵を生成するための
           シークレット       エントロピーソース


 クライアント    クライアント     クライアント
  書き込み      書き込み       書き込み
  MAC鍵       共通鍵     初期化ベクタIV

   サーバ       サーバ         サーバ
   書き込み     書き込み        書き込み
   MAC鍵      共通鍵      初期化ベクタIV
暗号通信の開始と
 ハンドシェイクの終了
 クライアント                       サーバ

           ChangeCipherSpec
        暗号スペックの変更を通知する。
        これ以降の通信は暗号化される。
暗号化
                                    Finishedを受け取ったら
されている          Finished
                                    検証データを検証し、鍵
        ハンドシェイクの終了                  交換と認証処理が成功し
        ・検証データ                      たことを確認する。
           ChangeCipherSpec
        暗号スペックの変更を通知する。
        これ以降の通信は暗号化される。
暗号化
されている          Finished
        ハンドシェイクの終了
        ・検証データ
アプリケーション データ
クライアント                  サーバ


         アプリケーション データ         上位のアプリケーション
    ・暗号化されたアプリケーション           (HTTP, IMAP, POP3など)
     データ                      を暗号化した通信はここで
                              行われる。
         アプリケーション データ

         アプリケーション データ

         アプリケーション データ
コネクションの終了
クライアント                  サーバ

         close_notify

    ・コネクションの終了を通知する終
    了アラート
ハンドシェイクが実現するもの
• 公開鍵証明書の検証
▫ 公開鍵証明書によるサーバやクライアントの認証
• クライアント乱数、サーバ乱数、プレ マスター
  シークレットの生成
▫ TLSレコードでの暗号化やMACで利用する共通鍵
  を生成するためのマスター シークレットを生成す
  るための乱数の提供
#mailerstudy 02 メールと暗号 - SSL/TLS -
復習)公開鍵基盤(PKI)                      ルート認証局

              OSやソフトウェアに
               バンドルして配布       ルート証明書

アリス
          ルート証明書
              公開鍵
                                       中間認証局
        署名の
        検証                    中間証明書

              署名
証明書パス     中間証明書
 の検証          公開鍵
                                         ボブ
        署名の
                              中間証明書
        検証
              署名
  ボブの     ボブの証明書
  公開鍵                         ボブの証明書
              公開鍵
                      一緒に配布
                      ボブが配布
サーバの管理者が設定すること
• 公開鍵証明書
 ▫ プライベート鍵
 ▫ サーバ公開鍵証明書(証明書チェーン)
 ▫ 中間CAの証明書
• 利用するSSL/TLSのバージョン
 ▫ 例)SSLv3 TLSv1
• 利用する暗号スイート
 ▫ OpenSSLを利用しているソフトウェアの場合
   HIGH, MEDIUM, LOW, EXPORT, aNULL
   例)ALL:!LOW:!SSLv2:!EXP:!aNULL
#mailerstudy 02 メールと暗号 - SSL/TLS -
SMTPS
• SMTPをSSL/TLSで暗号化するプロトコル
• TCP 465番ポート
 ▫ IANAに正式に登録された番号ではない!
 ▫ 一瞬登録されたけど失効された。
 ▫ 現在では慣習的に使っている。
SMTPS
• メーラーからSMTPサーバへのメールの送信時
  のみ利用されている。
• SMTPサーバ間の通信では利用されていない。
 ▫ 25番ポート以外は利用しない。
 ▫ 相手がSSL/TLSに対応しているかわからないから
   違うポート番号465なんて使えない。
 ▫ 25番ポートで通信できるSTARTTLSを使え
   ということで465番ポートは削除されたのではない
    かと推測
STARTTLS
• SMTPセッション中にTLS通信に切り替えるコマ
  ンド
• RFC 3207 SMTP Service Extension for
  Secure SMTP over Transport Layer Security
S:   220 mail.example.jp            C:   Client Key Exchange
C:   EHLO client.example.jp         C:   Change Server Spec
S:   250-mail.example.jp            C:   Finish                 暗号化さ
S:   250-PIPELINING                 S:   Change Server Spec     れている
S:   250-SIZE 102400000             S:   Finish
S:   250-VRFY                       C:   EHLO client.example.jp
S:   250-ETRN                       S:   250-mail.example.jp
S:   250-STARTTLS                   S:   250-PIPELINING
S:   250-ENHANCEDSTATUSCODES        S:   250-SIZE 102400000
S:   250-8BITMIME                   S:   250-VRFY
S:   250 DSN                        S:   250-ETRN
C:   STARTTLS                       S:   250-AUTH PLAIN LOGIN
S:   220 2.0.0 Ready to start TLS   S:   250-AUTH=PLAIN LOGIN
C:   Client Hello                   S:   250-ENHANCEDSTATUSCODES
S:   Server Hello                   S:   250-8BITMIME
S:   Certificate                    S:   250 DSN
S:   Server Key Exchange
S:   Server Hello Done
SMTPサーバとの接続確認
• SMTPSの場合
 ▫ openssl s_client -connect localhost:465
• STARTTLSの場合
 ▫ openssl s_client -connect localhost:587
   -starttls smtp
#mailerstudy 02 メールと暗号 - SSL/TLS -
POP3SとIMAPS
• POP3S
 ▫ POP3をSSL/TLSで暗号化するプロトコル
 ▫ TCP 995番ポート
• IMAPS
 ▫ IMAPをSSL/TLSで暗号化するプロトコル
 ▫ TCP 993番ポート
Using TLS with IMAP, POP3 and ACAP




      STARTTLS
        • POP3/IMAPセッション中にTLS通信に切り替え
          るコマンド
             ▫ POP3のコマンド名は短縮されて"STLS"である
        • RFC 2595 Using TLS with IMAP, POP3 and
          ACAP
             ▫ 平文認証(PLAIN, LOGIN)を保護する。
             ▫ STARTTLSを実装しているクライアントとサーバ
               は十分に強い暗号レイヤーがなければ、平文認証
               を拒否しなれればならない(MUST)
Using TLS with IMAP, POP3 and ACAP




      STARTTLS
        • 平文認証(PLAIN, LOGIN)の保護の背景
             ▫ APOPはプロトコル的に脆弱性がある
             ▫ APOPとCRAM-MD5はMD5の強度の問題がある。
             ▫ 実質的にクライアントとサーバの両方が実装して
               いる認証メカニズムはPLAINとLOGINくらいしか
               ない
             ▫ PLAINとLOGINは平文であるため、盗聴に弱い。
             ▫ では、TLSで暗号化しよう!
POP3のSTARTTLS
S:   +OK Dovecot ready               S:   Server Hello Done
C:   CAPA                            C:   Client Key Exchange
S:   +OK                             C:   Change Server Spec
S:   CAPA                            C:   Finish                暗号化さ
S:   TOP                             S:   Change Server Spec    れている
S:   UIDL                            S:   Finish
S:   RESP-CODES                      C:   CAPA
S:   PIPELINING                      S:   +OK
S:   STLS                            S:   CAPA
S:   SASL                            S:   TOP
C:   STLS                            S:   UIDL
S:   +OK Begin TLS negotiation now   S:   RESP-CODES
C:   Client Hello                    S:   PIPELINING
S:   Server Hello                    S:   USER
S:   Certificate                     S:   SASL PLAIN LOGIN
S:   Server Key Exchange             C:   USER foo
IMAPとSTARTTLS
S: OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID
ENABLE IDLE STARTTLS LOGINDISABLED] Dovecot ready.¥r¥n
C: 1 STARTTLS
S: 1 OK Begin TLS negotiation now
C: Client Hello
S: Server Hello
S: Certificate
S: Server Key Exchange
S: Server Hello Done
C: Client Key Exchange
C: Change Server Spec
C: Finish                                       暗号化さ
S: Change Server Spec                           れている
S: Finish
C: 2 CAPABILITY
S: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID
ENABLE IDLE AUTH=PLAIN AUTH=LOGIN
S: 2 OK Pre-login capabilities listed, post-login capabilities
have more.
IMAPサーバとの接続確認
• IMAPSの場合
 ▫ openssl s_client -connect ホスト名:993
• STARTTLSの場合
 ▫ openssl s_client -connect ホスト名:143
   -starttls imap
POP3サーバとの接続確認
• POP3Sの場合
 ▫ openssl s_client -connect localhost:995
• STARTTLSを使う場合
 ▫ openssl s_client -connect localhost:110
   -starttls pop3
まとめ
• SSL/TLSにより以下のことが実現できる
 ▫ 機密性(暗号化)
   通信内容が漏洩しないこと
 ▫ 完全性
   通信内容が改ざんされないこと
 ▫ 認証
   通信相手が本人であること
• SMTPS, POP3S, IMAPSはTLSにより透過的に暗号
  化できる。
• SMTP, POP3, IMAPのコネクション中にSTARTTLS
  コマンドを発行することにより、TLS通信に切り替
  えできる。

More Related Content

PDF
暗号技術入門 秘密の国のアリス 総集編
PDF
暗認本読書会10
PPTX
「ネットワーク超入門 IPsec VPN編」
PDF
SSL/TLSの基礎と最新動向
PDF
暗認本読書会9
PDF
Ansibleではじめるサーバー・ネットワークの自動化(2019/04版)
PDF
暗号化したまま計算できる暗号技術とOSS開発による広がり
PDF
とある診断員とSQLインジェクション
暗号技術入門 秘密の国のアリス 総集編
暗認本読書会10
「ネットワーク超入門 IPsec VPN編」
SSL/TLSの基礎と最新動向
暗認本読書会9
Ansibleではじめるサーバー・ネットワークの自動化(2019/04版)
暗号化したまま計算できる暗号技術とOSS開発による広がり
とある診断員とSQLインジェクション

What's hot (20)

PDF
Zabbixのパフォーマンスチューニング & インストール時の注意点
PDF
Optimistic Rollupとは何か
PPTX
フロー技術によるネットワーク管理
PDF
FIDO認証によるパスワードレスログイン実装入門
PDF
暗認本読書会7
PDF
Keycloak & midPoint の紹介
PDF
Hybrid Public Key Encryption (HPKE)
PDF
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
PDF
cloudpackサーバ仕様書(サンプル)
PDF
IIJmio meeting 5 MVNOとGPSについて
PDF
運用現場で常に隣り合わせの障害対応、IIJの出した答え
 
PDF
SDCCオープンネットワークのご紹介【2021/01版】
PDF
CTF for ビギナーズ ネットワーク講習資料
PDF
ウェブアプリケーションセキュリティ超入門
PPTX
Keycloak入門-OpenID ConnectによるAPIセキュリティ
PDF
自作ペアリング/BLS署名ライブラリの紹介
PDF
Fluentdで本番環境を再現
PDF
暗認本読書会12
PDF
オンプレを少しずつコンテナ化する
Zabbixのパフォーマンスチューニング & インストール時の注意点
Optimistic Rollupとは何か
フロー技術によるネットワーク管理
FIDO認証によるパスワードレスログイン実装入門
暗認本読書会7
Keycloak & midPoint の紹介
Hybrid Public Key Encryption (HPKE)
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
cloudpackサーバ仕様書(サンプル)
IIJmio meeting 5 MVNOとGPSについて
運用現場で常に隣り合わせの障害対応、IIJの出した答え
 
SDCCオープンネットワークのご紹介【2021/01版】
CTF for ビギナーズ ネットワーク講習資料
ウェブアプリケーションセキュリティ超入門
Keycloak入門-OpenID ConnectによるAPIセキュリティ
自作ペアリング/BLS署名ライブラリの紹介
Fluentdで本番環境を再現
暗認本読書会12
オンプレを少しずつコンテナ化する
Ad

Viewers also liked (9)

PDF
#logstudy 01 rsyslog入門
PDF
#mailerstudy 02 暗号入門 (2012-02-22更新)
PDF
いろいろなSSL/TLS設定ガイドライン (JNSA電子署名WG 実世界の暗号・認証技術勉強会資料)
PPTX
あんしんなWebサーバーのためのSSL設定
PPTX
SHA-256を学ぼうとする
PDF
脆弱性事例に学ぶセキュアコーディング「SSL/TLS証明書検証」編 (JavaDayTokyo2015)
PDF
Amazon CloudFront TLS/SSL Seminar 20160804
PDF
【19-C-L】Web開発者ならおさえておきたい「常時SSL/TLS化の実装ポイント」
PDF
Fluentdのお勧めシステム構成パターン
#logstudy 01 rsyslog入門
#mailerstudy 02 暗号入門 (2012-02-22更新)
いろいろなSSL/TLS設定ガイドライン (JNSA電子署名WG 実世界の暗号・認証技術勉強会資料)
あんしんなWebサーバーのためのSSL設定
SHA-256を学ぼうとする
脆弱性事例に学ぶセキュアコーディング「SSL/TLS証明書検証」編 (JavaDayTokyo2015)
Amazon CloudFront TLS/SSL Seminar 20160804
【19-C-L】Web開発者ならおさえておきたい「常時SSL/TLS化の実装ポイント」
Fluentdのお勧めシステム構成パターン
Ad

Similar to #mailerstudy 02 メールと暗号 - SSL/TLS - (20)

PDF
プロフェッショナルSSL/TLS 1.2章
PDF
Wp sslandroot certificate
PPT
コンバージョンに効く!?SSLサーバ処方箋
PPTX
Apache 2.4 新機能 “SSL編”
PPTX
AWSを学ぶ上で必要となる前提知識(SSL)
KEY
IPsecについて
PDF
『プロフェッショナルSSL/TLS』読書会3章
PDF
Fluentd message forwarding with authentication and encryption
PPTX
Let's Encryptについて話す【勉強会資料】
PPTX
TLS & LURK @ IETF 95
PPT
Professional SSL/TLS Reading Chapter 6
PDF
ただしくHTTPSを設定しよう!
 
PPT
平成21年度 秋期 cs 午前ⅱ
PDF
Javascript で暗号化
PDF
超簡単!TELNETの話
PPTX
SSL で守られる生活
PDF
TLS, HTTP/2演習
PPTX
SSLの技術的な仕組みとサイトのSSL化について
PDF
RFC7589(NETCONF Protocol over TLS)の勉強資料
PDF
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう
プロフェッショナルSSL/TLS 1.2章
Wp sslandroot certificate
コンバージョンに効く!?SSLサーバ処方箋
Apache 2.4 新機能 “SSL編”
AWSを学ぶ上で必要となる前提知識(SSL)
IPsecについて
『プロフェッショナルSSL/TLS』読書会3章
Fluentd message forwarding with authentication and encryption
Let's Encryptについて話す【勉強会資料】
TLS & LURK @ IETF 95
Professional SSL/TLS Reading Chapter 6
ただしくHTTPSを設定しよう!
 
平成21年度 秋期 cs 午前ⅱ
Javascript で暗号化
超簡単!TELNETの話
SSL で守られる生活
TLS, HTTP/2演習
SSLの技術的な仕組みとサイトのSSL化について
RFC7589(NETCONF Protocol over TLS)の勉強資料
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう

More from Takashi Takizawa (19)

PPTX
DNS RFCの歩き方(短縮版)
PDF
サバフェス! 2015 Spring LT資料
PPTX
BIND of Summer (2017-04-13)
PDF
Unbound/NSD最新情報(OSC 2014 Tokyo/Spring)
PDF
nginx入門
PDF
nginxの紹介
PDF
Unbound/NSD最新情報(OSC 2013 Tokyo/Spring)
PDF
RFCについての復習
PDF
DNS RFC系統図
PDF
DNSのRFCの歩き方
PPTX
initとプロセス再起動
PDF
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
PDF
Unboundの最適化(OSC2011 Tokyo/Spring)
PDF
qpstudy08 lsyncdによる共有ファイルシステムっぽい何かの検証
PDF
#mailerstudy 01 LT POP/IMAP入門
PDF
#dnstudy 01 ドメイン名の歴史
PDF
DNS再入門
PDF
#dnstudy 01 Unboundの紹介
PPTX
hbstudy20100821 SpamAssassin
DNS RFCの歩き方(短縮版)
サバフェス! 2015 Spring LT資料
BIND of Summer (2017-04-13)
Unbound/NSD最新情報(OSC 2014 Tokyo/Spring)
nginx入門
nginxの紹介
Unbound/NSD最新情報(OSC 2013 Tokyo/Spring)
RFCについての復習
DNS RFC系統図
DNSのRFCの歩き方
initとプロセス再起動
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
Unboundの最適化(OSC2011 Tokyo/Spring)
qpstudy08 lsyncdによる共有ファイルシステムっぽい何かの検証
#mailerstudy 01 LT POP/IMAP入門
#dnstudy 01 ドメイン名の歴史
DNS再入門
#dnstudy 01 Unboundの紹介
hbstudy20100821 SpamAssassin

#mailerstudy 02 メールと暗号 - SSL/TLS -

  • 1. メールサーバ勉強会 #mailerstudy 02 メールと暗号 - SSL/TLS - 株式会社ハートビーツ 滝澤 隆史
  • 2. 2 私は誰 • 氏名: 滝澤 隆史 @ttkzw • 所属: 株式会社ハートビーツ • 何やっている人 ▫ メーラMuttの国際化や日本語対応パッチ作者 ▫ SpamAssassinの日本語対応パッチ作者 • メールシステムとの関わり ▫ システム管理者として1997年から2006年までメールサー バの管理 ▫ 昔、qmail関連で色々やっていた。2006年にqmail捨て捨 て。Postfix/Dovecot遣いにクラスチェンジ ▫ 現在は個人サーバでメールサーバを運用  Postfix + Dovecot + Sieve(dovecot-pigeonhole) + ClamAV + SpamAssassin + spamass-milter + Roundcube
  • 4. 参考図書 • マスタリングTCP/IP SSL/TLS編 ▫ 著者: Eric Rescorla ▫ 出版社: オーム社 • 新版 暗号技術入門 秘密の国のアリス ▫ 著者: 結城 浩 ▫ 出版社:ソフトバンククリエイティブ • RFC • WikiPedia
  • 6. SSL/TLSとは • インターネット上の安全な通信を提供するプロ トコル ▫ 機密性(暗号化)  通信内容が漏洩しないこと ▫ 完全性  通信内容が改ざんされないこと ▫ 認証  通信相手が本人であること
  • 7. SSL/TLSとは • 透過性 ▫ TCPの通信を囲うトンネルのような役割 ▫ HTTP以外にも利用できる  SMTP, POP3, IMAP, LDAP, .....
  • 8. SSL/TLSとは • SSL ▫ Secure Socket Layerの略 • TLS ▫ Transport Layer Securityの略
  • 9. SSL/TLSの歴史 • SSL 1.0 ▫ ネットスケープコミュニケーションズ社により開発 ▫ 設計中に問題が見つかりリリースされなかった。 • SSL 2.0 ▫ 1994年発表 ▫ 最初に実装されたバージョン  Netscape Navigator 1.1 ▫ 様々なセキュリティ上の問題が見つかっている。 • SSL 3.0 ▫ 1995年発表  Netscape Navigator 2.0 ▫ 今でも使われている。
  • 10. SSL/TLSの歴史 • TLS 1.0 ▫ SSL 3.0のベースにして、 IETFによりインター ネット標準として開発された。 ▫ 1999年、RFC 2246 "The TLS Protocol Version 1.0"が公開 ▫ よく使われている。 ▫ CBC攻撃のリスク
  • 11. SSL/TLSの歴史 • TLS 1.1 ▫ 2006年、RFC 4346 "The Transport Layer Security (TLS) Protocol Version 1.1"が公開 ▫ CBC攻撃に対する耐性の強化 ▫ 実装があまり進んでいない。 • TLS 1.2 ▫ 2008年、RFC 5246 " The Transport Layer Security (TLS) Protocol Version 1.2"が公開 ▫ SHA-256のサポート ▫ 実装があまり進んでいない。
  • 12. SSL/TLSのバージョンのまとめ • SSL 2.0 ▫ ダウングレード攻撃の影響を受けるため、無効にしな いといけない。 • SSL 3.0, TLS 1.0 ▫ よく使われている。 ▫ CBC攻撃のリスク有り • TLS 1.1, TLS 1.2 ▫ TLS 1.1以降の利用が望ましい ▫ 実装が進んでいない  OpenSSL 1.0.1以降で対応  IE 8, IE 9(Windows 7, Windows 2008 R2)は対応  Opera 10は対応  Firefox, Chrome, Safariは非対応
  • 14. TLSプロトコル 暗号パラメータ アプリケーション 暗号スペックの データをTLSレコー アラートの通知 や乱数や公開鍵 変更の通知 ドプロトコルに渡す の交換 ChangeCipherSpec Alert Handshake プロトコル プロトコル プロトコル アプリケーション データ プロトコル TLSハンドシェイク プロトコル TLSレコード プロトコル ・上位プロトコルから受け取ったデータを暗号化してTLSレコードにする。 ・受け取ったTLSレコードを復号したデータを上位プロトコルに渡す。
  • 15. TLSレコード • TLSにおいて実際に暗号化されたデータとその ヘッダ ヘッダ 暗号文 コンテント プロトコル データ長 タイプ バージョン 上位のプロトコルタイプ SSL 3.0→3.0 ・change_cipher_spec TLS 1.0→3.1 ・alert TLS 1.1→3.2 ・handshake TLS 1.2→3.3 ・application_data 歴史的経緯↑
  • 16. TLSレコード 上位層から渡されたデータ ブロックデータを214 ブロックデータ(平文) (16384)バイト以下に分 割する。 フラグメント フラグメント フラグメントを圧縮する。 MACシークレットを共 圧縮 ヘッダ フラグメント MAC値 通鍵として、シーケン 圧縮フラグメント ス番号とヘッダと圧縮 とMAC値を共通鍵 フラグメントからMAC で暗号化する。 値を計算する。 ヘッダ 暗号文 暗号化により MAC値により完全性 機密性が保たれる。 の検証とメッセージ TLSレコード 認証を行う。
  • 17. TLSレコードが実現するもの • 暗号化 ▫ 機密性 • メッセージ認証コード(MAC) ▫ 完全性(改ざんされていないことの確認) ▫ メッセージ認証
  • 18. TLSレコードだけでは 実現できないもの • 共通鍵の交換(鍵配送問題) • 公開鍵証明書の検証 • 利用する暗号スイートの合意 • →ハンドシェイクで行う
  • 19. TLS通信の流れ • 次の段階に分けられる ▫ ハンドシェイク ▫ アプリケーション データ ▫ コネクションの終了 • 通信の流れを見てみよう ▫ ただし、  サーバ認証  RSA認証 ▫ の場合についてのみ説明
  • 20. 通信の流れ クライアント サーバ ClientHello 利用する暗号スイートを ServerHello 決めたり、鍵を生成する Certificate ための乱数や証明書のや ServerHelloDone りとりを行う。 ClientKeyExchange ハンドシェイク ChangeCipherSpec Finished ChangeCipherSpec 暗号化したデータのやり Finished とりを行う。 アプリケーション データ アプリケーション データ close_notify 終了
  • 21. Helloメッセージ クライアント サーバ ClientHello ・プロトコル バージョン ・クライアントが生成した乱数 ・セッションID ・利用できる暗号スイートのリスト クライアントとサーバ間 ・圧縮方法 で互いに利用可能なセ キュリティ情報の交換を ServerHello 行う。 ・プロトコル バージョン ・サーバが生成した乱数 ・セッションID ・利用する暗号スイート ・圧縮方法
  • 22. Helloメッセージ クライアント サーバ Certificate ・公開鍵証明書のチェイン ・サーバの証明書 ・中間CAの証明書 ・ルートCAの証明書 クライアントがすでに持って いることを前提に省略可 クライアントは ServerHelloDone ServerHelloDoneを受 け取った後に、サーバの ServerHelloの終了を知らせる。 証明書の検証を行う。
  • 23. 復習)公開鍵基盤(PKI) ルート認証局 OSやソフトウェアに バンドルして配布 ルート証明書 アリス ルート証明書 公開鍵 中間認証局 署名の 検証 中間証明書 署名 証明書パス 中間証明書 の検証 公開鍵 ボブ 署名の 中間証明書 検証 署名 ボブの ボブの証明書 公開鍵 ボブの証明書 公開鍵 一緒に配布 ボブが配布
  • 24. プレ マスター シークレットの送信 クライアント サーバ ClientKeyExchange クライアントは公開鍵で 暗号化して送り、サーバ ・公開鍵で暗号化された はプライベート鍵で復号 プレ マスター シークレット する。 安全にプレ マスター シー クレットを送信できる。 マスター シークレット を生成するのに利用する クライアントで生成した 乱数
  • 25. マスター シークレット クライアント プレ マスター サーバの の乱数 シークレット 乱数 マスター 鍵を生成するための シークレット エントロピーソース クライアント クライアント クライアント 書き込み 書き込み 書き込み MAC鍵 共通鍵 初期化ベクタIV サーバ サーバ サーバ 書き込み 書き込み 書き込み MAC鍵 共通鍵 初期化ベクタIV
  • 26. 暗号通信の開始と ハンドシェイクの終了 クライアント サーバ ChangeCipherSpec 暗号スペックの変更を通知する。 これ以降の通信は暗号化される。 暗号化 Finishedを受け取ったら されている Finished 検証データを検証し、鍵 ハンドシェイクの終了 交換と認証処理が成功し ・検証データ たことを確認する。 ChangeCipherSpec 暗号スペックの変更を通知する。 これ以降の通信は暗号化される。 暗号化 されている Finished ハンドシェイクの終了 ・検証データ
  • 27. アプリケーション データ クライアント サーバ アプリケーション データ 上位のアプリケーション ・暗号化されたアプリケーション (HTTP, IMAP, POP3など) データ を暗号化した通信はここで 行われる。 アプリケーション データ アプリケーション データ アプリケーション データ
  • 28. コネクションの終了 クライアント サーバ close_notify ・コネクションの終了を通知する終 了アラート
  • 29. ハンドシェイクが実現するもの • 公開鍵証明書の検証 ▫ 公開鍵証明書によるサーバやクライアントの認証 • クライアント乱数、サーバ乱数、プレ マスター シークレットの生成 ▫ TLSレコードでの暗号化やMACで利用する共通鍵 を生成するためのマスター シークレットを生成す るための乱数の提供
  • 31. 復習)公開鍵基盤(PKI) ルート認証局 OSやソフトウェアに バンドルして配布 ルート証明書 アリス ルート証明書 公開鍵 中間認証局 署名の 検証 中間証明書 署名 証明書パス 中間証明書 の検証 公開鍵 ボブ 署名の 中間証明書 検証 署名 ボブの ボブの証明書 公開鍵 ボブの証明書 公開鍵 一緒に配布 ボブが配布
  • 32. サーバの管理者が設定すること • 公開鍵証明書 ▫ プライベート鍵 ▫ サーバ公開鍵証明書(証明書チェーン) ▫ 中間CAの証明書 • 利用するSSL/TLSのバージョン ▫ 例)SSLv3 TLSv1 • 利用する暗号スイート ▫ OpenSSLを利用しているソフトウェアの場合  HIGH, MEDIUM, LOW, EXPORT, aNULL  例)ALL:!LOW:!SSLv2:!EXP:!aNULL
  • 34. SMTPS • SMTPをSSL/TLSで暗号化するプロトコル • TCP 465番ポート ▫ IANAに正式に登録された番号ではない! ▫ 一瞬登録されたけど失効された。 ▫ 現在では慣習的に使っている。
  • 35. SMTPS • メーラーからSMTPサーバへのメールの送信時 のみ利用されている。 • SMTPサーバ間の通信では利用されていない。 ▫ 25番ポート以外は利用しない。 ▫ 相手がSSL/TLSに対応しているかわからないから 違うポート番号465なんて使えない。 ▫ 25番ポートで通信できるSTARTTLSを使え  ということで465番ポートは削除されたのではない かと推測
  • 36. STARTTLS • SMTPセッション中にTLS通信に切り替えるコマ ンド • RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security
  • 37. S: 220 mail.example.jp C: Client Key Exchange C: EHLO client.example.jp C: Change Server Spec S: 250-mail.example.jp C: Finish 暗号化さ S: 250-PIPELINING S: Change Server Spec れている S: 250-SIZE 102400000 S: Finish S: 250-VRFY C: EHLO client.example.jp S: 250-ETRN S: 250-mail.example.jp S: 250-STARTTLS S: 250-PIPELINING S: 250-ENHANCEDSTATUSCODES S: 250-SIZE 102400000 S: 250-8BITMIME S: 250-VRFY S: 250 DSN S: 250-ETRN C: STARTTLS S: 250-AUTH PLAIN LOGIN S: 220 2.0.0 Ready to start TLS S: 250-AUTH=PLAIN LOGIN C: Client Hello S: 250-ENHANCEDSTATUSCODES S: Server Hello S: 250-8BITMIME S: Certificate S: 250 DSN S: Server Key Exchange S: Server Hello Done
  • 38. SMTPサーバとの接続確認 • SMTPSの場合 ▫ openssl s_client -connect localhost:465 • STARTTLSの場合 ▫ openssl s_client -connect localhost:587 -starttls smtp
  • 40. POP3SとIMAPS • POP3S ▫ POP3をSSL/TLSで暗号化するプロトコル ▫ TCP 995番ポート • IMAPS ▫ IMAPをSSL/TLSで暗号化するプロトコル ▫ TCP 993番ポート
  • 41. Using TLS with IMAP, POP3 and ACAP STARTTLS • POP3/IMAPセッション中にTLS通信に切り替え るコマンド ▫ POP3のコマンド名は短縮されて"STLS"である • RFC 2595 Using TLS with IMAP, POP3 and ACAP ▫ 平文認証(PLAIN, LOGIN)を保護する。 ▫ STARTTLSを実装しているクライアントとサーバ は十分に強い暗号レイヤーがなければ、平文認証 を拒否しなれればならない(MUST)
  • 42. Using TLS with IMAP, POP3 and ACAP STARTTLS • 平文認証(PLAIN, LOGIN)の保護の背景 ▫ APOPはプロトコル的に脆弱性がある ▫ APOPとCRAM-MD5はMD5の強度の問題がある。 ▫ 実質的にクライアントとサーバの両方が実装して いる認証メカニズムはPLAINとLOGINくらいしか ない ▫ PLAINとLOGINは平文であるため、盗聴に弱い。 ▫ では、TLSで暗号化しよう!
  • 43. POP3のSTARTTLS S: +OK Dovecot ready S: Server Hello Done C: CAPA C: Client Key Exchange S: +OK C: Change Server Spec S: CAPA C: Finish 暗号化さ S: TOP S: Change Server Spec れている S: UIDL S: Finish S: RESP-CODES C: CAPA S: PIPELINING S: +OK S: STLS S: CAPA S: SASL S: TOP C: STLS S: UIDL S: +OK Begin TLS negotiation now S: RESP-CODES C: Client Hello S: PIPELINING S: Server Hello S: USER S: Certificate S: SASL PLAIN LOGIN S: Server Key Exchange C: USER foo
  • 44. IMAPとSTARTTLS S: OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS LOGINDISABLED] Dovecot ready.¥r¥n C: 1 STARTTLS S: 1 OK Begin TLS negotiation now C: Client Hello S: Server Hello S: Certificate S: Server Key Exchange S: Server Hello Done C: Client Key Exchange C: Change Server Spec C: Finish 暗号化さ S: Change Server Spec れている S: Finish C: 2 CAPABILITY S: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN S: 2 OK Pre-login capabilities listed, post-login capabilities have more.
  • 45. IMAPサーバとの接続確認 • IMAPSの場合 ▫ openssl s_client -connect ホスト名:993 • STARTTLSの場合 ▫ openssl s_client -connect ホスト名:143 -starttls imap
  • 46. POP3サーバとの接続確認 • POP3Sの場合 ▫ openssl s_client -connect localhost:995 • STARTTLSを使う場合 ▫ openssl s_client -connect localhost:110 -starttls pop3
  • 47. まとめ • SSL/TLSにより以下のことが実現できる ▫ 機密性(暗号化)  通信内容が漏洩しないこと ▫ 完全性  通信内容が改ざんされないこと ▫ 認証  通信相手が本人であること • SMTPS, POP3S, IMAPSはTLSにより透過的に暗号 化できる。 • SMTP, POP3, IMAPのコネクション中にSTARTTLS コマンドを発行することにより、TLS通信に切り替 えできる。