一応補足。 S/MIMEは電子メールの保護用の技術で、暗号化および署名の2つの機能がある。 暗号化の方はPPAPの解決策…になるんだけど、受信側でS/MIME用の公開鍵証明書を取得して、予め送信側に配布してないといけないので。実はそう広がらないんじゃないかな、的な。 今回の話は署名の方。これももちろん証明書の取得が必要だけど、「発信内容の保証」ということで、企業からの情報発信で使われるケースはそこそこある。

これは、Let's Encryptを支えるこの二人のルートCAと OpenSSLの物語である。 DST Root CA X3 (2000-2021) ISRG Root X1 (2015-2035) 〜2021年1月〜 ISRG Root X1「いままで一緒にやってきたDST Root CA X3さんの寿命が間近・・・このままだと僕を信頼してくれていないベテランの（具体的にいうと2016年くらいまでの）古いクライアントたちは Let's Encryptさんを信用してくれなくなっちゃう・・・どうしよう」 DST Root CA X3「どれ、わしが死ぬ前に(有効期限が切れる前に)お前が信頼に値する旨を一筆書いて残せばいいじゃろう。サラサラ」 Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3 Validity Not Bef

インターネットの安全を支えるOpenSSL TLSはインターネットを安全に利用する上で欠かすことのできない重要な要素だ。そして、その実装系のひとつであるOpenSSLは多くのサーバ管理者にとって欠かすことのできないソフトウェアとなっている。 ユーザーの多くはOpenSSLについて気にも留めていないか、パワーユーザーであればOpenSSLを暗号系のライブラリまたはフレームワークといった類のもの、という認識を持っているのではないだろうか。Webサーバの管理者であれば、Webサーバをセットアップする最初の段階で証明書の作成に利用するツールという認識を持っているかもしれない。しかし、OpenSSLはそれだけのソフトウェアではない。 OpenSSLは証明書署名要求や自己署名証明書の生成のみならず、ファイルの暗号化や復号化、証明書の検証や証明書有効期限の確認など、さまざまな機能を提供するコマンドでもあ

AkamaiとMicrosoftらによって、QUIC用APIを実装したOpenSSLのforkが公開されています。 github.com これらは、公式がQUIC用APIをサポートするまでの一次的なソリューションとのことですが、流れを簡単に整理しておく。 目次 背景: QUICとTLS OpenSSL 3.0とQUICサポートの見解 forkされたOpenSSL その他の動き 背景: QUICとTLS QUICと呼ばれる新しいトランスポートプロトコルは、IETFで標準化が進められていましたが、RFCがもうすぐ出るところまできています。 このQUICでは通信を暗号化しますが、コネクションを確立する際に、TLS1.3相当のメッセージをやりとりしサーバ認証および鍵の共有を行います。 （詳細については 「QUIC-TLS」の仕様を御覧ください） そこで、QUICを実装するに当たり暗号ライブラリとし

はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名（前提知識） この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

こちらは改訂前の旧版のページです。改題第2版の商品ページをご覧ください Webセキュリティ解説の決定版 "Bulletproof SSL and TLS" の全訳（原書2017年版へのアップグレード済み） Ivan Ristić 著、齋藤孝道 監訳 520ページ B5判 ISBN：978-4-908686-00-9 電子書籍の形式：PDF 2020年7月4日 第1版第5刷 発行（原書2017年版アップグレード対応済み） 本サイトにてユーザ登録のうえ購入いただくと、原著改訂第2版に収録されるTLS 1.3の解説章を付録として含んだ特別版PDFがお読みいただけます 現代生活を支えるネットワークにとって、通信の暗号化は不可欠の機能です。しかし、実際のインターネットで暗号化通信を利用できるようにするには、暗号化アルゴリズムの知識だけでなく、セキュリティプロトコルとその実装技術、さらに、基盤となる信

はじめに 背景と目的 元ネタは、@ozuma5119氏のスライド個人でEV SSL証明書が欲しい話でした。スライド36枚目から、オレオレEVSSL証明書1を作ってブラウザ(Firefox)に認識させようという試みが説明されているのですが、結局成功していませんでした。 そこでこの話に触発されて、 オレオレEVSSL証明書をブラウザ(Firefox)に認識させることはできるのか 件のスライドの説明よりもっと楽な方法はないか 件のスライドでうまく行かなかった理由は何か を調べた話になります。 前提 SSL/TLSの本当に基礎については、拙記事SSL/TLSの見落とされがちな「認証」という基本機能をご覧ください。その中でEVについても軽く触れています。 また、今回の話の全体像をつかむためには、冒頭で紹介したスライドを一読されることをお勧めします。 注意 本記事の趣旨はあくまで、ブラウザがEVだと認

追記: (2015/8/3) 大量のはてブが付いたので 続き を書きました。 sshを使用している人は文字列を手軽に暗号化・復号化できるという話。 このテクニックを使えば色々セキュアになるのでおすすめ。 今回はシェルスクリプト中の平文パスワードをセキュアに代替する。 平文パスワードはやめよう シェルスクリプト中でパスワードが必要になったとき、 とりあえず平文で書いてしまいがち。 #!/bin/sh PASSWORD="hoge" これをセキュアにしたい。 面倒くさいのは嫌なので、なるべく手持ちのツールで暗号化、復号化したい。 ssh用の rsa 秘密鍵と、openssl(大抵の環境に入っている)を使って改善しよう。 秘密鍵の準備 パスワードを暗号化するにあたって、秘密鍵を使用する． sshを常用している場合は ~/.ssh/id_rsa という秘密鍵が存在するだろう。 もし秘密鍵が無ければ

GmailのSMTPサーバの基本的な情報はここに載ってる http://mail.google.com/support/bin/answer.py?answer=78799 サーバ: smtp.gmail.com ポート: 465 or 587 アカウント: xxxxxxxx@gmail.com パスワード: yyyyyyyy(Gmailのパスワード) Use STARTTLS STARTTLSを使用するのでサーバへの接続は openssl s_clientを使用します。 $ openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:587 接続できたらehlo ehlo localhost 250-AUTH LOGIN PLAIN XOAUTH次はSMTP-AUTH認証を行ないます。 認証方式はPLAINでやってみます。