SlideShare a Scribd company logo
1 of 47
Download to read offline
メールサーバ勉強会 #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
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は非対応
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で利用する共通鍵
  を生成するためのマスター シークレットを生成す
  るための乱数の提供
復習)公開鍵基盤(PKI)                      ルート認証局

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

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

              署名
証明書パス     中間証明書
 の検証          公開鍵
                                         ボブ
        署名の
                              中間証明書
        検証
              署名
  ボブの     ボブの証明書
  公開鍵                         ボブの証明書
              公開鍵
                      一緒に配布
                      ボブが配布
サーバの管理者が設定すること
• 公開鍵証明書
 ▫ プライベート鍵
 ▫ サーバ公開鍵証明書(証明書チェーン)
 ▫ 中間CAの証明書
• 利用するSSL/TLSのバージョン
 ▫ 例)SSLv3 TLSv1
• 利用する暗号スイート
 ▫ OpenSSLを利用しているソフトウェアの場合
   HIGH, MEDIUM, LOW, EXPORT, aNULL
   例)ALL:!LOW:!SSLv2:!EXP:!aNULL
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
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

What's hot

Amazon S3 고급 활용 기법 - AWS Summit Seoul 2017
Amazon S3 고급 활용 기법  - AWS Summit Seoul 2017Amazon S3 고급 활용 기법  - AWS Summit Seoul 2017
Amazon S3 고급 활용 기법 - AWS Summit Seoul 2017
Amazon Web Services Korea
 
AWS KMS를 활용하여 안전한 AWS 환경을 구축하기 위한 전략::임기성::AWS Summit Seoul 2018
AWS KMS를 활용하여 안전한 AWS 환경을 구축하기 위한 전략::임기성::AWS Summit Seoul 2018 AWS KMS를 활용하여 안전한 AWS 환경을 구축하기 위한 전략::임기성::AWS Summit Seoul 2018
AWS KMS를 활용하여 안전한 AWS 환경을 구축하기 위한 전략::임기성::AWS Summit Seoul 2018
Amazon Web Services Korea
 
OpenID ConnectとSCIMの標準化動向
OpenID ConnectとSCIMの標準化動向OpenID ConnectとSCIMの標準化動向
OpenID ConnectとSCIMの標準化動向
Tatsuo Kudo
 

What's hot (20)

Amazon S3 고급 활용 기법 - AWS Summit Seoul 2017
Amazon S3 고급 활용 기법  - AWS Summit Seoul 2017Amazon S3 고급 활용 기법  - AWS Summit Seoul 2017
Amazon S3 고급 활용 기법 - AWS Summit Seoul 2017
 
AWS KMS를 활용하여 안전한 AWS 환경을 구축하기 위한 전략::임기성::AWS Summit Seoul 2018
AWS KMS를 활용하여 안전한 AWS 환경을 구축하기 위한 전략::임기성::AWS Summit Seoul 2018 AWS KMS를 활용하여 안전한 AWS 환경을 구축하기 위한 전략::임기성::AWS Summit Seoul 2018
AWS KMS를 활용하여 안전한 AWS 환경을 구축하기 위한 전략::임기성::AWS Summit Seoul 2018
 
AWSからのメール送信
AWSからのメール送信AWSからのメール送信
AWSからのメール送信
 
OpenID ConnectとSCIMの標準化動向
OpenID ConnectとSCIMの標準化動向OpenID ConnectとSCIMの標準化動向
OpenID ConnectとSCIMの標準化動向
 
AWS Black Belt Online Seminar AWS Key Management Service (KMS)
AWS Black Belt Online Seminar AWS Key Management Service (KMS) AWS Black Belt Online Seminar AWS Key Management Service (KMS)
AWS Black Belt Online Seminar AWS Key Management Service (KMS)
 
[社内勉強会]ELBとALBと数万スパイク負荷テスト
[社内勉強会]ELBとALBと数万スパイク負荷テスト[社内勉強会]ELBとALBと数万スパイク負荷テスト
[社内勉強会]ELBとALBと数万スパイク負荷テスト
 
OpenID Connect のビジネスチャンス
OpenID Connect のビジネスチャンスOpenID Connect のビジネスチャンス
OpenID Connect のビジネスチャンス
 
Ssl in a nutshell
Ssl in a nutshellSsl in a nutshell
Ssl in a nutshell
 
AWS Black Belt Online Seminar 2017 Amazon Athena
AWS Black Belt Online Seminar 2017 Amazon AthenaAWS Black Belt Online Seminar 2017 Amazon Athena
AWS Black Belt Online Seminar 2017 Amazon Athena
 
암호화 이것만 알면 된다.
암호화 이것만 알면 된다.암호화 이것만 알면 된다.
암호화 이것만 알면 된다.
 
Awsをオンプレドメコンに連携させる
Awsをオンプレドメコンに連携させるAwsをオンプレドメコンに連携させる
Awsをオンプレドメコンに連携させる
 
NET304_Deep Dive into the New Network Load Balancer
NET304_Deep Dive into the New Network Load BalancerNET304_Deep Dive into the New Network Load Balancer
NET304_Deep Dive into the New Network Load Balancer
 
アイデンティティ (ID) 技術の最新動向とこれから
アイデンティティ (ID) 技術の最新動向とこれからアイデンティティ (ID) 技術の最新動向とこれから
アイデンティティ (ID) 技術の最新動向とこれから
 
Microservices Manchester: Authentication in Microservice Systems by David Borsos
Microservices Manchester: Authentication in Microservice Systems by David BorsosMicroservices Manchester: Authentication in Microservice Systems by David Borsos
Microservices Manchester: Authentication in Microservice Systems by David Borsos
 
AWS Lambda ハンズオン 2-Tier アーキテクチャで未来へ
AWS Lambda ハンズオン 2-Tier アーキテクチャで未来へAWS Lambda ハンズオン 2-Tier アーキテクチャで未来へ
AWS Lambda ハンズオン 2-Tier アーキテクチャで未来へ
 
Office365導入時のDNS設定の注意点
Office365導入時のDNS設定の注意点Office365導入時のDNS設定の注意点
Office365導入時のDNS設定の注意点
 
Security Best Practices on AWS
Security Best Practices on AWSSecurity Best Practices on AWS
Security Best Practices on AWS
 
20190129 AWS Black Belt Online Seminar AWS Identity and Access Management (AW...
20190129 AWS Black Belt Online Seminar AWS Identity and Access Management (AW...20190129 AWS Black Belt Online Seminar AWS Identity and Access Management (AW...
20190129 AWS Black Belt Online Seminar AWS Identity and Access Management (AW...
 
Deep dive into AWS fargate
Deep dive into AWS fargateDeep dive into AWS fargate
Deep dive into AWS fargate
 
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューションOAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
 

Viewers also liked

あんしんなWebサーバーのためのSSL設定
あんしんなWebサーバーのためのSSL設定あんしんなWebサーバーのためのSSL設定
あんしんなWebサーバーのためのSSL設定
Takayuki Ino
 

Viewers also liked (8)

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

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

Wp sslandroot certificate
Wp sslandroot certificateWp sslandroot certificate
Wp sslandroot certificate
Yoshida Yuri
 
Man-in-the-Middle Attack for SSH with Scala and JSch
Man-in-the-Middle Attack for SSH with Scala and JSchMan-in-the-Middle Attack for SSH with Scala and JSch
Man-in-the-Middle Attack for SSH with Scala and JSch
Atsuhiko Yamanaka
 

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

Wp sslandroot certificate
Wp sslandroot certificateWp sslandroot certificate
Wp sslandroot certificate
 
SSLの技術的な仕組みとサイトのSSL化について
SSLの技術的な仕組みとサイトのSSL化についてSSLの技術的な仕組みとサイトのSSL化について
SSLの技術的な仕組みとサイトのSSL化について
 
プロフェッショナルSSL/TLS 1.2章
プロフェッショナルSSL/TLS 1.2章プロフェッショナルSSL/TLS 1.2章
プロフェッショナルSSL/TLS 1.2章
 
Professional SSL/TLS Reading Chapter 14
Professional SSL/TLS Reading Chapter 14Professional SSL/TLS Reading Chapter 14
Professional SSL/TLS Reading Chapter 14
 
AWSを学ぶ上で必要となる前提知識(SSL)
AWSを学ぶ上で必要となる前提知識(SSL)AWSを学ぶ上で必要となる前提知識(SSL)
AWSを学ぶ上で必要となる前提知識(SSL)
 
OAuthのHolder of Key Token
OAuthのHolder of Key TokenOAuthのHolder of Key Token
OAuthのHolder of Key Token
 
公開鍵、秘密鍵ってなに?
公開鍵、秘密鍵ってなに?公開鍵、秘密鍵ってなに?
公開鍵、秘密鍵ってなに?
 
Xml Security
Xml SecurityXml Security
Xml Security
 
脆弱性事例に学ぶセキュアコーディング「SSL/TLS証明書検証」編 (KOF2014)
脆弱性事例に学ぶセキュアコーディング「SSL/TLS証明書検証」編 (KOF2014)脆弱性事例に学ぶセキュアコーディング「SSL/TLS証明書検証」編 (KOF2014)
脆弱性事例に学ぶセキュアコーディング「SSL/TLS証明書検証」編 (KOF2014)
 
1/5 ADFS 2.0 を使用してWindows Azure との SSO を実現しよう v1.1
1/5 ADFS 2.0 を使用してWindows Azure との SSO を実現しよう v1.11/5 ADFS 2.0 を使用してWindows Azure との SSO を実現しよう v1.1
1/5 ADFS 2.0 を使用してWindows Azure との SSO を実現しよう v1.1
 
Professional SSL/TLS Reading Chapter 6
Professional SSL/TLS Reading Chapter 6Professional SSL/TLS Reading Chapter 6
Professional SSL/TLS Reading Chapter 6
 
Man-in-the-Middle Attack for SSH with Scala and JSch
Man-in-the-Middle Attack for SSH with Scala and JSchMan-in-the-Middle Attack for SSH with Scala and JSch
Man-in-the-Middle Attack for SSH with Scala and JSch
 
RFC7589(NETCONF Protocol over TLS)の勉強資料
RFC7589(NETCONF Protocol over TLS)の勉強資料RFC7589(NETCONF Protocol over TLS)の勉強資料
RFC7589(NETCONF Protocol over TLS)の勉強資料
 
Azure Container Services and Microservices design pattern
Azure Container Services and Microservices design patternAzure Container Services and Microservices design pattern
Azure Container Services and Microservices design pattern
 
『プロフェッショナルSSL/TLS』読書会3章
『プロフェッショナルSSL/TLS』読書会3章『プロフェッショナルSSL/TLS』読書会3章
『プロフェッショナルSSL/TLS』読書会3章
 
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
 
WindowsAzureの長所を活かすクラウド アプリ開発(PDF版)
WindowsAzureの長所を活かすクラウド アプリ開発(PDF版)WindowsAzureの長所を活かすクラウド アプリ開発(PDF版)
WindowsAzureの長所を活かすクラウド アプリ開発(PDF版)
 
AWS Client VPN
AWS Client VPNAWS Client VPN
AWS Client VPN
 
さくらのクラウドDNS経由でワイルドカード証明書を後からインストールしたcertbotで取得する方法
さくらのクラウドDNS経由でワイルドカード証明書を後からインストールしたcertbotで取得する方法さくらのクラウドDNS経由でワイルドカード証明書を後からインストールしたcertbotで取得する方法
さくらのクラウドDNS経由でワイルドカード証明書を後からインストールしたcertbotで取得する方法
 
デブサミ2014【14-E-L】暗号破りに新たな攻撃!進化する脅威に対抗するためのwebサイトセキュリティとsslの進化(林正人〔日本ベリサイン〕)
デブサミ2014【14-E-L】暗号破りに新たな攻撃!進化する脅威に対抗するためのwebサイトセキュリティとsslの進化(林正人〔日本ベリサイン〕)デブサミ2014【14-E-L】暗号破りに新たな攻撃!進化する脅威に対抗するためのwebサイトセキュリティとsslの進化(林正人〔日本ベリサイン〕)
デブサミ2014【14-E-L】暗号破りに新たな攻撃!進化する脅威に対抗するためのwebサイトセキュリティとsslの進化(林正人〔日本ベリサイン〕)
 

More from Takashi Takizawa

BIND of Summer (2017-04-13)
BIND of Summer (2017-04-13)BIND of Summer (2017-04-13)
BIND of Summer (2017-04-13)
Takashi Takizawa
 
Unbound/NSD最新情報(OSC 2013 Tokyo/Spring)
Unbound/NSD最新情報(OSC 2013 Tokyo/Spring)Unbound/NSD最新情報(OSC 2013 Tokyo/Spring)
Unbound/NSD最新情報(OSC 2013 Tokyo/Spring)
Takashi Takizawa
 
initとプロセス再起動
initとプロセス再起動initとプロセス再起動
initとプロセス再起動
Takashi Takizawa
 
#mailerstudy 01 LT POP/IMAP入門
#mailerstudy 01 LT POP/IMAP入門#mailerstudy 01 LT POP/IMAP入門
#mailerstudy 01 LT POP/IMAP入門
Takashi Takizawa
 
#dnstudy 01 ドメイン名の歴史
#dnstudy 01 ドメイン名の歴史#dnstudy 01 ドメイン名の歴史
#dnstudy 01 ドメイン名の歴史
Takashi Takizawa
 
#dnstudy 01 Unboundの紹介
#dnstudy 01 Unboundの紹介#dnstudy 01 Unboundの紹介
#dnstudy 01 Unboundの紹介
Takashi Takizawa
 

More from Takashi Takizawa (19)

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

Recently uploaded

Recently uploaded (7)

LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアルLoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
 
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半        2024/04/26の勉強会で発表されたものです。新人研修 後半        2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
 
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
 
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイスLoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
 
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
 
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
 
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
 

#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
  • 5.
  • 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は非対応
  • 13.
  • 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で利用する共通鍵 を生成するためのマスター シークレットを生成す るための乱数の提供
  • 30.
  • 31. 復習)公開鍵基盤(PKI) ルート認証局 OSやソフトウェアに バンドルして配布 ルート証明書 アリス ルート証明書 公開鍵 中間認証局 署名の 検証 中間証明書 署名 証明書パス 中間証明書 の検証 公開鍵 ボブ 署名の 中間証明書 検証 署名 ボブの ボブの証明書 公開鍵 ボブの証明書 公開鍵 一緒に配布 ボブが配布
  • 32. サーバの管理者が設定すること • 公開鍵証明書 ▫ プライベート鍵 ▫ サーバ公開鍵証明書(証明書チェーン) ▫ 中間CAの証明書 • 利用するSSL/TLSのバージョン ▫ 例)SSLv3 TLSv1 • 利用する暗号スイート ▫ OpenSSLを利用しているソフトウェアの場合  HIGH, MEDIUM, LOW, EXPORT, aNULL  例)ALL:!LOW:!SSLv2:!EXP:!aNULL
  • 33.
  • 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
  • 39.
  • 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通信に切り替 えできる。