cert-manager基礎知識
cert-managerとは kubernetesクラスタ上でSSL/TLS証明書をシンプルに扱うためのツールです。 証明書の取得・更新・利用が簡単になります。 公式ドキュメント この記事の内容 この記事では、cert-managerを利用していくにあたり、最低限おさえておきたい「証明書発行・利用の流れ」と、「登場人物」だけを簡単にまとめます。 証明書まわりは分かりづらいし、事故ったら大変なことになるので、あまり触りたくない箇所かもしれませんが、基礎知識を知っておくことで最初の足がかりになると思います。 cert-manager v1.6.1での話をしていきます。 また、Let's EncryptをIssuerとした流れを説明しますので、他のIssuer Typeでは内容が異なる箇所があります。 証明書発行・利用の簡単な流れ まずざっくりとした流れを書いておきます。 実際のインストール方法
イラストで正しく理解するTLS 1.3の暗号技術
イラストで正しく理解するTLS 1.3の暗号技術 初めに ここではTLS 1.3（以下TLSと略記）で使われている暗号技術を解説します。 主眼はTLSのプロトコルではなく、「暗号技術」の用語の挙動（何を入力して何を出力するのか）と目的の理解です。 実際にどのような方式なのかといった、より詳しい説明は拙著『図解即戦力 暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』（暗認本）や『暗認本』の内容を紹介したスライドや動画などの資料集をごらんください。 なお表題の「イラストで」は数式を使わないという程度の意味です。 TLSで守りたいもの TLSはコンピュータ同士が安全に通信するための規格です。 主に人がブラウザを介して「https://」で始まるWebサイトにアクセスするときに利用されます。 安全に通信するためには、通信内容が盗聴されても情報が漏れない機密性が必要です。 それから通信が改
Linuxのkernel TLSでnginxのSSL_sendfileを試してみた · hnakamur's blog
2021-10-31 はじめに OpenSSLのSSL_sendfileとパッチを当てたnginxでLinuxのkTLSを試してみた · hnakamur’s blog を書いてから1年半経って状況が変わっていたので再度試してみました。 9日前に SSL: SSL_sendfile() support with kernel TLS. · nginx/nginx@1fc61b7 で Linux の kernel TLS を使って sendfile するコードが nginx に入っていました。 コミットメッセージによると enable-tls オプションを有効にした OpenSSL 3.0 が必要とのことです。 検証環境 $ cat /etc/os-release | grep ^VERSION= VERSION="20.04.3 LTS (Focal Fossa)" $ uname -r
SSL/TLSのハンドシェイクってどんなの？ - Qiita
ようこそ、SSL/TLS Advent Calendarへ！ QiitaもようやくSSLになったので、このカレンダーを読んでいる人はほぼ確実にqiita.comへのSSL接続を済ませていることかと思います。では、その接続とはどのような形で行われるものなのか、考えたことがある人はそんなに多くないかもしれません。 今回は、初回にふさわしく、SSL1の接続を開始してから成立するまでを考えていきます。 ハンドシェイクに要求されるもの 実際の流れを見ていく前に、SSLのハンドシェイクにはどのような特性が必要か考えてみましょう。両者で合意しないといけないものとしては、以下のようなものがあります。 使用する暗号化などの鍵スイート 使う暗号鍵 そして、ハンドシェイクにおいても次のような要件が必要です。 （切断以外の）中間者攻撃に耐えられる 鍵は第三者から特定不能な形で共有する 正しく接続できなければ接続を
SSL/TLS（SSL3.0～TLS1.2）のハンドシェイクを復習する
以下順を追って説明します。 HelloRequest 相手にClientHelloを送信するよう促すメッセージです。送信しなくても構いません。 ClientHello ServerHello ClientHelloとServerHelloは、TLSのひとつめの肝です。後ほど説明します。 ServerCertificate サーバ証明書を送信します。中間CA証明書なども、ここで送ります。 ServerKeyExchange 鍵交換メッセージその１です。鍵交換はTLSのふたつめの肝で、これも後ほど説明します。 CertificateRequest クライアント証明書を送信するように促すメッセージです。クライアント証明書が必要な場合に送信します。何そのクライアント証明書って？と思った方は読み飛ばして構いません。 ServerHelloDone サーバからの送信終了を示すエンドマークです。 Cli
TLS Cipher Suite
TLS/SSL 暗号スイート TLS/SSL では，ハンドシェイクプロトコルによってサーバとクライアントの双方が利用可能な暗号アルゴリズムを決定します．利用する暗号アルゴリズムは，鍵交換方法（RSA, DHなど），共通鍵暗号アルゴリズム（AES, RC4 など）と暗号動作モード (CBC，GCM など) ，およびハッシュ関数（MD5, SHA1 など）の組み合せで，暗号スイート (Cipher Suite) と呼ばれます． TLS/SSL プロトコルにおいて，どの暗号スイートを使うかは通信の安全性に大きな影響を及ぼします．そのため，安全性が低い暗号スイートは使わないようにするなど，サーバおよびクライアントにおける適切な設定が必要です． TLS における暗号スイートの検索がWebサイト TLS Ciphersuite Search で行えます．暗号強度の評価 (Weak, Secure, R
TLS証明書チェッカーcheck-tls-certの公開
こんにちは、技術開発室の滝澤です。 TLS証明書チェッカーcheck-tls-certを開発して公開したので紹介します。 このcheck-tls-certについて簡単に説明すると次の通りです。 check-tls-certは、TLS証明書の有効性と証明書チェインの検証するツール 主な用途は、TLS証明書の設置・更新作業の際の各種確認およびTLS証明書の（有効期限を含む）有効性の監視 様々な検査を実施し、各検査結果を出力することで問題箇所を把握しやすい check-tls-certの概要 TLS証明書チェッカーcheck-tls-certはTLS証明書の有効性と証明書チェインを検証します。 主にTLS証明書の設置・更新作業の際の各種確認およびTLS証明書の（有効期限を含む）有効性の監視のために利用できます。 次のサイトで公開しており、ReleaseページからLinux向けとmacOS向けのバ
中国がTLS 1.3とESNIを使用するHTTPSトラフィックをブロック
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 中国政府は、国内の通信を検閲するシステムである「グレートファイアウォール」（GFW）をアップデートし、通信のインターセプト（傍受、妨害）を防止する最新のセキュリティプロトコルを使ったHTTPS接続をブロックし始めた。 中国の検閲状況を調査している3つの組織（iYouPort、メリーランド大学、Great Firewall Report）が米国時間8月7日に発表した共同レポートによれば、この状況は7月末から始まっているという。 中国政府はHTTPS＋TLS 1.3＋ESNIの接続をブロック GFWのアップデートで新たに標的になったのは、「TLS 1.3」や「ESNI」（Encrypted Server Name Indication）など
Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる | おそらくはそれさえも平凡な日々
追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST
求む！TLS1.3の再接続を完全に理解した方(Challenge CVE-2020-13777) - ぼちぼち日記
1. GnuTLSの深刻な脆弱性(CVE-2020-13777) 先日、GnuTLSで深刻な脆弱性が見つかりました。 GNUTLS-SA-2020-06-03: CVE-2020-13777 It was found that GnuTLS 3.6.4 introduced a regression in the TLS protocol implementation. This caused the TLS server to not securely construct a session ticket encryption key considering the application supplied secret, allowing a MitM attacker to bypass authentication in TLS 1.3 and recover previous c
nginx で TLS 1.3 の Cipher Suites を設定するメモ - tech memo
この記事の概要 ssl_ciphers では TLS 1.3 の ciphers を設定できない経緯 nginx + openssl で TLS 1.3 の Ciphers を設定してみる 1 . ssl_protocols に TLS 1.3 を追加する ( デフォルトの cipher 利用 ) 2. openssl.cnf にて Ciphersuites を定義する 蛇足 追記 ( 2020年7月7日 ) この記事の概要 nginx 1.17.5 で確認した話を書いています。今後の進展がある可能性があります。 ssl_ciphers では TLS 1.3 の ciphers を設定できない経緯 nginx の ssl_ciphers では TLS 1.3 の ciphers を設定できません。現時点では、TLS 1.3 の ciphers を設定する方法がnginx標準機能としてはあり
Google Chrome EV表示の終焉 - ぼちぼち日記
1. Chrome でEV証明書の組織名表示がなくなる ついにGoogleからChromeのURLバーからEV表示を削除する正式なアナウンスが出ました。 Upcoming Change to Chrome's Identity Indicators EV UI Moving to Page Info 現在(2019年8月) StableのChrome76では、以下の様にURLバー左側にEV証明書を利用していることを示す「組織名+国名」表示が付いています。 Chrome76のEV表示 2019年9月10日Stableリリース予定のChrome77からはEV表示がURLバーから削除され、鍵アイコンをクリックして表示されるPage Infoに「組織名＋国名」が表示されるようになります。 Googleのアナウンスでは、 "on certain websites" と書いてあることから一気にではなく
政府によるインターネットの検閲とSNIについて
しかし今回一般の人の目にも触れる形でSNIやHTTPSのことが報じられた結果、エンジニアも含めて明らかに技術に関して勘違いをしているのではないかと感じる発言を見ることがありました。このまま放置するのも良くないと感じているので、Q&Aという形でSNIやHTTPSに関する誤解を少しでも解ければと思います。 Q&AQ: そもそもSNIって何？以前書いた記事にも書かれているので是非読んでみてください。 簡単に説明すると、HTTPSではSSL/TLSを利用して通信が暗号化されます。なので1つのIPアドレスで複数の証明書を扱おうとした場合、最初の通信時にどの証明書を利用すればいいか分かりません。そこでSNIが必要になります。 SNIは最初の通信時に今から通信したいサーバーネーム（ドメイン名と考えてください）をサーバーに平文で渡すことで、通信したいSSL証明書を指定できます。SNIは現在の一般的なブラウ
Encrypted SNI / TLSハンドシェイクの暗号化 - Qiita
SNI とは 一つのIPアドレスと一つのTCPポートで、複数のWebサイトをホスティングする技術の一つに、virtualhostがあります。 これは、HTTPリクエスト内で指定するドメイン名から、同じIPに対するアクセスをドメインごとに振り分ける機能です。 たとえば、以下のコマンドを実行すると、こんな出力がされます。 （ちなみに、vがリクエストヘッダの表示、 Iがボディの非表示のオプションです。） $ curl -v -I example.com * Trying xxxxx... * TCP_NODELAY set * Connected to example.com (xxxxx) port 80 (#0) > HEAD / HTTP/1.1 > Host: example.com > User-Agent: curl/7.62.0 > Accept: */* > …（省略） 真ん中の
J-STAGEがFirefoxでのアクセスを遮断、日本の電子ジャーナルが世界から不可視となった日｜Guest｜note
科学技術振興機構（以下JST）の運営する「J-STAGE」は、国立情報学研究所が運営する「CiNii」と双璧を成す、日本の電子ジャーナルプラットフォームである。それが2018年12月12日、Firefoxからのアクセスが不可能となった。 試しにFirefox 64でアクセスしてみたところ、確かにページ読み込みエラーとなり、コンテンツを表示することができなかった。サーバ証明書のエラーではないため例外を許可して続行することもできない。完全にFirefoxでのアクセスが遮断された格好だ。 翌日13日になってTwitterで原因の考察が始まり、J-STAGEの対応する暗号スイートに問題があることが判明する。 原因はJ-STAGEのTLS仕様違反J-STAGEはセキュリティ強化のため、2018年12月12日にTLS 1.2への切替とTLS 1.0/1.1の無効化を行うことを予告していた。これが影響し
複数のTLS実装でのCAT(Cache-like ATacks)の脆弱性 (RSA鍵交換の危険性) - OSS脆弱性ブログ
OSSに関するセキュリティ・ツールの使い方・脆弱性等を紹介しています。 SELinux/Capability/AntiVirus/SCAP/SIEM/Threat Intelligence等。 OSS脆弱性ブログ11/30/2018にThe 9 Lives of Bleichenbacher's CAT: New Cache ATtacks on TLS Implementationsというサイトと論文が公開されました。これによると、PKCS #1 v1.5 標準に従ったRSAに対する新たなパディングオラクル攻撃の手法が見つかったそうです。この新たな攻撃( Cache-like ATacks (CATs) )を9つのTLS実装に試したところ、7つのTLS実装で問題が発見され、ダウングレード攻撃を用いて30秒以内に利用可能な5台のTLSサーバからRSA平文の全ての2048ビットを復元すること
The 9 Lives of Bleichenbacher's CAT: New Cache ATtacks on TLS Implementations
The 9 Lives of Bleichenbacher's CAT: New Cache ATtacks on TLS Implementations Eyal Ronen, Robert Gillham, Daniel Genkin, Adi Shamir, David Wong and Yuval Yarom Download Full Paper ‘‘Those who’ll play with cats must expect to be scratched.’’ – Miguel de Cervantes, Don Quixote. Abstract At CRYPTO'98, Bleichenbacher published his seminal paper which described a padding oracle attack against RSA imple
TLS 1.3の標準化と実装 | IIJ Engineers Blog
IIJ-II 技術研究所 技術開発室の山本です。現在技術開発室は、私を含めた4人で構成されており、主にプログラミング言語Haskellを使って開発を進めています。今回の話題である TLS(Transport Layer Security) 1.3 もHaskellで実装しました。 4年の歳月をかけて議論されてきたTLS 1.3ですが、この8月にめでたく仕様がRFC 8446となりました。貢献者リストに私の名前が載っていることを聞きつけた広報から、ブログ記事の執筆依頼がありましたので、TLS 1.3の標準化や実装の話について書いてみます。 なぜTLS 1.3を標準化する必要があったのか理由を知りたい方は、「TLSの動向」という記事や「TLS 1.3」というスライドを読んで下さい。 インターネットで使われているプロトコルは、IETFという団体で仕様が議論されて策定されます。IETFには、誰でも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TLS 1.0/1.1サイトは完全にブロック ～「Google Chrome 98」安定版がリリース／軽量カラーベクターフォント「COLRv1」をサポート。脆弱性の修正は27件
祝RFC！Transport Layer Security (TLS) 1.3 発行の軌跡 ～熟成された4年間の安全性解析～｜株式会社レピダム
