Intro Web サービスをデプロイする際に、CA から証明書を取得し HTTPS で暗号化するのが一般的となった。 かつては "SSL 証明書" として、メールでやり取りし有料で購入するのが常識だったが、自動/無料で取得することが増えた。かつては 5~10 年あった有効期限もどんどん短くなり、今では 6 日の証明書も発行されている。 このように、証明書を取り巻く変遷は目覚ましく、それは Web を取り巻く環境の劇的な変化を色濃く反映した結果と言える。 http:// が https:// になった裏で何が起こり、これからどうなっていくのか。まとめていく。 (極力ソースを付記するが、既に消えて WebArchive にも残っていないものも多く、筆者の記憶に頼る情報も多い。) 黎明期 (90 年代後半~2010 年頃) 90 年代の終わり頃、当時は TLS の前身にあたる SSL のデプロ
So yesterday I set out to protect my Google App Engine (GAE) API with HTTPS. I had already set up my Google App Engine instance. I was vaguely familiar with Let’s Encrypt (https://letsencrypt.org/), although I had never used it. I also had a basic grasp of cryptographic primitives used in encryption and certificates. There are a lot of blog posts out there about this along with a bunch of StackOve
$ mkcert -install Created a new local CA 💥 The local CA is now installed in the system trust store! ⚡️ The local CA is now installed in the Firefox trust store (requires browser restart)! 🦊 $ mkcert example.com "*.example.com" example.test localhost 127.0.0.1 ::1 Created a new certificate valid for the following names 📜 - "example.com" - "*.example.com" - "example.test" - "localhost" - "127.0.0
TLSは特定のアプリケーション層プロトコルに依存しないため、HTTP以外にも多くのプロトコルにおいて採用され、クレジットカード情報や個人情報、その他の機密情報を通信する際の手段として活用されている。 既存のアプリケーション層プロトコルでTLSを利用する場合、大きく2つの適用方式が考えられる。まずひとつは、下位層（通常はTCP）の接続を確立したらすぐにTLSのネゴシエーションを開始し、TLS接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。もうひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でTLSへの切り替えを指示する方式である。切り替えコマンドとしてSTARTTLSが広まっているため、この方式自体をSTARTTLSと呼ぶこともある。 前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、平文で接続を開始する
要件 MySQL でグローバル IP をまたぐレプリケーションをやってみたい その場合、通信は SSL で暗号化したい 手始めに同一ホスト内から SSL を使って接続を試してみる 環境 Amazon Linux 手順 MySQL のインストール yum install -y mysql-serverChef のレシピ的には以下で... package "mysql-server" do action :install end service "mysql_service" do case node["platform"] when "CentOS","RedHat","Fedora","amazon" service_name "mysqld" else service_name "mysql" end supports :status => true, :restart => true,
Webサイト2016.02.08 2019.12.27 電子証明書の種類！sslサーバー証明書とクライアント証明書の仕組み 近年、ID・パスワードだけで認証するWEBサイトに対しての、なりすまし被害が急増しています。個人向けのWEBサイトのみならず、企業が従業員向けで用意しているリモートアクセス環境にも被害が拡大中です。 そのような被害を防ぐために、電子証明書を利用する企業が増えてきています。電子証明書の代表的な種類として、sslサーバー証明書とクライアント証明書があります。 ここでは電子証明書がどういう仕組みのものなのかを説明していきます。 SSLクライアント認証電子証明書を用いた認証というと、よく知られているのはSSLサーバー証明書のサーバー認証です。サーバー認証は、WEBサイトへアクセスしたユーザーが、正規のWEBサイトにアクセスしているかを確認するための認証です。 SSLクライアン
MySQL 5.7.6からSSL周りのセットアップが扱いやすくなった
MySQL :: MySQL 5.7 Release Notes :: Changes in MySQL 5.7.6 (2015-03-09, Milestone 16) から抜粋。 MySQL Server from Community Edition distributions now tries to deploy with SSL support enabled automatically if no SSL options are specified explicitly and it finds any of the ca.pem, server-cert.pem, and server-key.pem files in the data directory. In this case, clients can use a secure connection merely by
Web over HTTPS DevFest Tokyo 2016 #devfest16 2016/10/0
ウェブブラウザにおけるTLS/SSLの対応状況の変化 ウェブブラウザ バージョン プラットフォーム SSLプロトコル TLSプロトコル 証明書のサポート 脆弱性への対応[注 1] プロトコル選択[注 2] SSL 2.0 (安全ではない) SSL 3.0 (安全ではない) TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 EV[注 3][1] SHA-2[2] ECDSA[3] BEAST [注 4] CRIME [注 5] POODLE (SSLv3) [注 6] RC4 [注 7] FREAK [4][5] Logjam Google Chrome (Chrome for Android) [注 8] [注 9]
意外にハマったのでメモ。 OCSPとは OCSP（Online Certificate Status Protocol）とは、SSL/TLS暗号化通信の初期フェーズにおいて証明書の失効を確認するための手順。 従来は署名所失効リスト(CRL)が利用されていたが、CRLはリストが肥大化しダウンロードに非常に時間がかかるようになってきたため、単一レコードの取得で済むOCSPが、現在では証明書の失効を確認する方法として一般的になった。 OCSP Staplingとは 通常は以下の図のように、証明書をダウンロードしたクライアントがOCSP Responderにサーバ証明書の失効を確認する。 OCSP Staplingに対応すると、以下の図のように証明書の失効確認をサーバ側で処理することができる。 また、OCSPレスポンスは一定の間はサーバにキャッシュされ、都度OCSP Responderに問い合わせ
Amazonギフトカードの使い方や使える店 Amazonカードは、Amazonの支払いで使えるギフトカードです。Amazonでの買い物以外でも、Kindle本やAmazonプライム会員費の支払いにも使用可能です。他にもAmazon Pay加盟店での支払いやAmazonミュージックやプライムビデオの有料のタイトルやレンタルにも使用できます。 Amazon Pay加盟店の具体例としては、家電量販店のECサイトだとアイリスオーヤマ公式通販サイトやアイリスプラザ、コジマネット、イオシス。実店舗では成城石井や劇団四季、J!NS、オンラインではZOZOTOWNや出前館、FOD、るるぶトラブルなどがあります。 Amazon Payは1万社以上の10万以上のECサイトや実店舗で利用できます。 Amazonギフトカードの換金方法 Amazonギフトカードの換金方法は以下の3つです ギフトカード買取サイトで換
TLS has exactly one performance problem: it is not used widely enough. Everything else can be optimized. Data delivered over an unencrypted channel is insecure, untrustworthy, and trivially intercepted. We owe it to our users to protect the security, privacy, and integrity of their data — all data must be encrypted while in flight and at rest. Historically, concerns over performance have been the
インフラエンジニアの方向けに、SSL/TLSとは何か、また証明書入手のポイント、HTTPS設定のポイントについて、最新の動向を踏まえて紹介します。また、最後の方で勉強会主催者のリクエストでおまけがあります(^^;
ご無沙汰しております。細羽です。 昨年、AndroidにおけるSNI対応状況という記事で、SSL/TLSの拡張仕様であるSNI(Server Name Indication)について触れました。 少しニッチなテーマだと思っていましたが、つい先日、さくらのレンタルサーバでSNI SSLを提供開始というプレスリリースが発表されました。広いサービスでSSL/TLS導入への需要が高まっている今、このような事例は今後増えていくものと考えられます。 そこで本記事では、重要度が高まっているSNIについて、その技術の概要を改めて理解し、実際の運用に役立てられるように整理をしたいと思います。 知識の整理を目的にした前編と、実践を目的にした後編の2部構成でお届けします。 以下が前編の内容です。 SNIで何が出来るようになるのか SNIで複数ドメインが運用可能になるまで SNIが重要になりつつある背景 SSL運
Lenovo製のPCの一部にSuperfishというマルウェアが標準でインストールされていることが確認され、大きな問題となっています。 [2015-11-24追記] DELL製のPCにも、「eDellRoot」とされるSuperfishと同様の問題を持つルート証明書が導入されているようです。 DellのPCに不審なルート証明書、LenovoのSuperfishと同じ問題か - ITmedia エンタープライズ Dude, You Got Dell’d: Publishing Your Privates - Blog - Duo Security Joe Nord personal blog: New Dell computer comes with a eDellRoot trusted root certificate https://t.co/chURwV7eNE eDellRootで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
