政府によるインターネットの検閲とSNIについて
しかし今回一般の人の目にも触れる形でSNIやHTTPSのことが報じられた結果、エンジニアも含めて明らかに技術に関して勘違いをしているのではないかと感じる発言を見ることがありました。このまま放置するのも良くないと感じているので、Q&Aという形でSNIやHTTPSに関する誤解を少しでも解ければと思います。 Q&AQ: そもそもSNIって何？以前書いた記事にも書かれているので是非読んでみてください。 簡単に説明すると、HTTPSではSSL/TLSを利用して通信が暗号化されます。なので1つのIPアドレスで複数の証明書を扱おうとした場合、最初の通信時にどの証明書を利用すればいいか分かりません。そこでSNIが必要になります。 SNIは最初の通信時に今から通信したいサーバーネーム（ドメイン名と考えてください）をサーバーに平文で渡すことで、通信したいSSL証明書を指定できます。SNIは現在の一般的なブラウ
理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 · けんごのお屋敷
apache や nginx の設定をしたことがあれば以下の様な行を見たことがある人も多いのではないでしょうか。(※ 下記は nginx の設定。apache の場合は SSLCipherSuite です。) ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; これが暗号スイートを指定している箇所です。そしてこの部分、わけのわからない文字列の羅列なのですごく取っつきにくくて何を指定したらいいかわからないので、コピペしてしまう人も多いんじゃないでしょうか。かくいう私も数年前に趣味で TLS 対応の Web サービスを作った時はコピペで済ませていました。この暗号スイートは、以下のような OpenSSL のコマンドを使って対応している一覧を見ることができます。 $ openssl ciphers -v AES128-SH
Certificate Transparencyについて勉強会で発表したので、その補足や落ち穂拾い - ろば電子が詰まつてゐる
終了後にメモするのをサボっていたら1週間経ってしまいましたが、主催している「すみだセキュリティ勉強会」を久々に開催しました。 すみだセキュリティ勉強会2015#1 発表者の@inaz2さん、@furandon_pigさん、ありがとうございました。 今回の発表内容 私の発表は、最近ちょっと気になっているCertificate Transparencyについてでした。発表資料は以下です（パワポ資料を、ノート付きPDFにしています）。 俺とお前とCertificate Transparency 内容については資料を見てもらうとして、以下、時間内で話せなかった部分などを補足します。 復習と用語整理 まず、用語を思い出しておきましょう。 CT: Certificate Transparency。CTログサーバに発行した証明書を登録することで、証明書発行の「透明性」を確保する仕組み。 SCT: Sig
Symantecが再びGoogleの信頼を失った件についてのメモ - Technically, technophobic.
（初めに言い訳しておくと、証明書界隈については詳しくないです。某誤訳量産サイトが適当な記事を書いていたので、なにか書かねばと思って書いているという程度のまとめ記事です。間違いなどあればご指摘ください） 何が起こるのか Ryan Sleeviさん（Googleの人）がBlink-devのメーリングリストに投稿したこれにまとまっています：https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ 経緯についてはいったん飛ばして、どのようなアクションが提案されているのか見ます。 To restore confidence and security of our users, we propose the following steps: A reduction in the accepted
GoogleはSpectreとMeltdownの対策を昨年6月に開始し12月には完了していた。性能低下の報告はなし
GoogleはSpectreとMeltdownの対策を昨年6月に開始し12月には完了していた。性能低下の報告はなし インテルやAMD、ARMなど、現在使われているほぼすべてのCPUに影響する深刻な脆弱性「Spectre」と「Meltdown」が表面化した問題について、Googleはすでに半年以上前、2017年6月にこの脆弱性への対策を開始し、12月には完了していたことを明らかにしました。 現時点では多くの報道などにおいて、この脆弱性に対処するための修正を行うとCPUの性能低下を引き起こす可能性があることが指摘されています。またインテルは脆弱性対策のためのファームウェアを適用すると、デスクトップPC向けのベンチマークにおいて、6パーセントかそれ以下の性能低下の可能性があると発表しています（サーバ用途における性能低下の影響についてはまだインテルから発表されていません）。 ところがGoogleは
CPUの脆弱性 MeltdownとSpectreについてまとめてみた - piyolog
2018年1月3日にCPUに関連する3つの脆弱性情報が公開されました。報告者によるとこれらの脆弱性はMeltdown、Spectreと呼称されています。ここでは関連情報をまとめます。 脆弱性の概要 報告者が脆弱性情報を次の専用サイトで公開した。 Meltdown and Spectre (またはこちら) 3つの脆弱性の概要をまとめると次の通り。 脆弱性の名称 Meltdown Spectre CVE CVE-2017-5754（Rogue data cache load） CVE-2017-5753（Bounds check bypass） CVE-2017-5715（Branch target injection） 影響を受けるCPU Intel Intel、AMD、ARM CVSSv3 基本値 4.7(JPCERT/CC) 5.6(NIST) ←に同じ PoC 報告者非公開 論文中にx
Googleが発見した「CPUの脆弱性」とは何なのか。ゲーマーに捧ぐ「正しく恐れる」その方法まとめ - 4Gamer.net
Googleが発見した「CPUの脆弱性」とは何なのか。ゲーマーに捧ぐ「正しく恐れる」その方法まとめ ライター：米田 聡 一般メディアにもニュースとして取り上げられたので，2017年末からにわかに騒がれだした「CPUの脆弱性」については，4Gamer読者も多くが聞き及んでいることだろう。海外では，「Spectre」（スペクター）や「Meltdown」（メルトダウン）といったおどろおどろしい名前が付いているので，そちらを目にしたという読者もいると思う。 「Intel製のCPUだけが持つ脆弱性で，AMD製のCPUなら問題ない」から始まって，「いやいやAMD製のCPUも同様の脆弱性を抱えている」，さらには「メモリページング方式の仮想記憶を使うCPUのすべてが持つ脆弱性である」などと，情報が錯綜しているので，何を信じたらいいのか分からないという人も多いのではなかろうか。そもそも，メモリページング方式
「パスワードは定期的に変更してはいけない」--米政府 （ニューズウィーク日本版） - Yahoo!ニュース
＜アメリカの電子認証専門機関が、定期的なパスワード変更の推奨をやめると決めた。エンドユーザーもいずれ、代わりの新しい「パスフレーズ」を要求されるようになるはすだ＞ 米政府機関はもう、パスワードを定期的に変えるのを推奨しない。アメリカの企画標準化団体、米国立標準技術研究所（NIST）が発行する『電子認証に関するガイドライン』の新版からルールを変更する。 ウェブサイトやウェブサービスにも、サイトが乗っ取られたのでもない限り、「パスワードが長期間変更されていません」などの警告を定期的に表示するのを止めるよう勧告するという。銀行や病院のように人に知られてはいけない個人情報を扱う機関も同じだという。 【参考記事】パスワード不要の世界は、もう実現されている？！ 実は近年、情報セキュリティー専門家の間でも、特別の理由がない限り、ユーザーにパスワード変更を求めるべきではないという考え方が増えてきた
ImageMagickの脆弱性(CVE-2016-3714他)についてまとめてみた 2016-05-04 - piyolog
画像処理ソフトImageMagickに複数の脆弱性が存在するとして2016年5月3日頃、CVE-2016-3714他の脆弱性情報が公開されました。ここでは関連情報をまとめます。 ImageMagick 開発チームの情報 2016年5月3日 ImageMagick Security Issue 脆弱性情報 対象 ImageMagick CVE CVE-2016-3714 CVE-2016-3715 CVE-2016-3716 CVE-2016-3717 CVE-2016-3718 影響 RCE 重要度 CVE-2016-3714：Important(Redhat)/緊急(JPCERT/CC) PoC PoC公開あり。 in the wildとの情報もあり。 CVSS(v2) CVE-2016-3714：6.8(Redhat)/9.3(CERT/CC) 発見者 Nikolay Ermishki
Neverbleed - RSAの秘密鍵演算を別プロセスに分離する話
機能毎にプロセスを分割し、それらを別個の権限のもとで実行することで、脆弱性があった場合の影響を抑え込むというのは、一定以上の規模をもつプログラムでは、しばしば見られるデザインパターンです。 qmailは、そのような設計がなされたメール配送デーモンとして名高いですし、OpenSSHもまた、認証プロセスと通信プロセスを分離することで、外部との通信を担当するコードにバグがあったとしても、ルート権限が奪われないように設計されています（参照: Privilege Separated OpenSSH）。 一方で、OpenSSLにはそのような権限分離は実装されていません。Heartbleedの際にサーバの秘密鍵が漏洩したのも、秘密鍵の取り扱いと、その他の通信の取り扱いを同一のメモリ空間の中で行っていたからだと考えることができます。 ないのなら、自分で作ればいいじゃない…ということで作りました。それが、N
5分でわかる正しい Web サイト常時 SSL 化のための基礎知識
Web サイトを常時 SSL 化する場合に、最低限知っておかなければならない知識や、注意点、実際の設定方法まで、ひと通りまとめてみました。メリットやデメリット、証明書の種別からリダイレクト設定などについても解説しています。 HTTPS をランキングシグナルに使用しますと Google が公式に発表したあたりから、Web サイトの SSL 対応、特に Google が推奨している Web サイトをすべて HTTPS で配信する、所謂 「常時 SSL 化」 についての話を聞いたり、実際にお客様から相談されたりするケースが増えてきました。 そこで、いい機会だしその辺に関する情報をまとめておこうかな～ と思って書いてみた、恒例の （？） 5分でわかるシリーズ。書き終わって見たところ絶対に 5分じゃ無理っていう文章量になっててどうしようかなぁとも思ったんですが、気にせず公開してみます。 常時 SSL
シェルスクリプトの平文パスワードをセキュアにする方法 - 余白の書きなぐり
追記: (2015/8/3) 大量のはてブが付いたので 続き を書きました。 sshを使用している人は文字列を手軽に暗号化・復号化できるという話。 このテクニックを使えば色々セキュアになるのでおすすめ。 今回はシェルスクリプト中の平文パスワードをセキュアに代替する。 平文パスワードはやめよう シェルスクリプト中でパスワードが必要になったとき、 とりあえず平文で書いてしまいがち。 #!/bin/sh PASSWORD="hoge" これをセキュアにしたい。 面倒くさいのは嫌なので、なるべく手持ちのツールで暗号化、復号化したい。 ssh用の rsa 秘密鍵と、openssl(大抵の環境に入っている)を使って改善しよう。 秘密鍵の準備 パスワードを暗号化するにあたって、秘密鍵を使用する． sshを常用している場合は ~/.ssh/id_rsa という秘密鍵が存在するだろう。 もし秘密鍵が無ければ
前方秘匿性 (forward secrecy) をもつウェブサイトの正しい設定方法
前方秘匿性（forward secrecy）とは、以下のような性質を指します。 公開鍵暗号の秘密鍵のように、比較的長期に渡って使われる鍵が漏えいしたときでも、それまで通信していた暗号文が解読されないという性質 鍵が漏れることも想定せよ――クラウド時代における「楕円曲線暗号」の必然性 - @IT 鍵が攻撃者や諜報機関など第三者の知るところとなった場合でも、それまで通信していた暗号文が解読されないようにしないといけない、という考え方とともに、最近 HTTPS を利用するウェブサイトにおいても導入が求められるようになってきた概念です。 前方秘匿性を満たすウェブサイトの設定方法については、TLSの暗号化方式をECDH_RSAあるいはECDHE_RSAに設定すれば良い、と述べている文献が多いです。 ですが、ほとんどのウェブサーバにおいて、それは誤りです。 なぜか。 通信を暗号化する鍵（セッション鍵）
TLSの普及へサーバ証明書を無料発行、MozillaやCiscoが認証局を創設
「Let's Encrypt」のサービスでは誰でもワンクリックで簡単に自分のドメイン用のベーシックなサーバ証明書を入手して実装できるようにする。 インターネット上の通信を暗号化するTLSの普及を目指し、手軽に実装できるサーバ証明書を無料で発行する認証局（CA）の「Let's Encrypt」が、MozillaやCisco Systemsといった大手のバックアップで創設された。 TLSを利用するためには、通信相手のサーバが本物であることを認証するための証明書をサーバ運用者が取得する必要がある。しかしこうした証明書は一般的には有料で、正しくインストールするのが難しく、アップデートにも手間がかかるとLet's Encryptは指摘する。 こうした問題を解決するため、Let's Encryptのサービスでは誰でもワンクリックで簡単に自分のドメイン用のベーシックなサーバ証明書を入手して実装できるよう
OpenSSLの脆弱性(CVE-2015-1793)によるAltチェーン証明書偽造の仕組み - ぼちぼち日記
TL;DR やっぱり書いていたら長文になってしまいました。あまりちゃんと推敲する気力がないので、変な文章になっているかもしれません。ご了承いただける方のみお読みください。 1. はじめに 昨晩未明にOpenSSL-1.0.2d, 1.0.1pがリリースされました。事前に予告されていた通り深刻度高の脆弱性CVE-2015-1793が修正されています。Advisoryを見ると、この脆弱性がiojs/Nodeに影響があるということが判明したので直ちにiojs/Nodeのアップデートを行い、今朝未明に無事脆弱性対応版をリリースしました。 今回が初めてではありませんが、深夜に日欧米のエンジニアがgithub上で互いに連携しながら速やかにセキュリティ対策のリリース作業を行うことは何回やってもなかなかしびれる経験です。時差もありなかなか体力的には辛いものがありますが、世界の超一流のエンジニアと共同でリア
Norikraでwebサービスを守る話をしてきた - 酒日記 はてな支店
Norikra meetup #2でLTをしてきました。LTといいつつ時間に余裕があったので15分以上しゃべっていたような… atnd.org 発表資料はこちらです。 speakerdeck.com Norikraで不正アクセスの兆候があるアクセスログを検知して、検知次第IPアドレスをmemcachedに突っ込んでそれをもとにアクセスをブロックする、というネタでした。 ログの流し込みが詰まった場合に誤爆しないように、結果のtimestampに1分以上の間隔があった場合は max(time) - min(time) で補正するとか、クエリに後処理で使うための定数を埋め込んでおくことでクエリごとに挙動を調整しやすくするとか、そんなかんじの細かい工夫をしています。 あと皆さん気になっていたNorikraの冗長化ですが、active-standby構成であればすぐできる気はします。 うちはいまst
年金機構の情報流出を見てちょっと思ったこと [ほほほのほ]
いつもならFaceBookに先に書いているんだけど、今日はこっちに。あとでFBにも貼る。 いつものごとく時間がないので、雑感を駄文で。 年金機構が所謂職員の失敗で、年金情報を流出するという事件が発生した。 詳しいまとめは、いつものごとく、高速に素晴らしいまとめをしてくれる日本年金機構の情報漏えいについてまとめてみたを参照。Kangoさん、いつも本当に素晴らしい。 さて。この事件とか事件について色々喋っている人とか、大臣と呼ばれる人とかを見ていて感じた雑感を。 非常に大量に情報を流出してしまった事件としては、ベネッセ事件があった。詳しくはベネッセの情報漏えいをまとめてみた。を参照。 この事件において、ベネッセは様々な方面から散々ぶん殴られた。マスコミもJIPDECも利用者も、好きなようにベネッセをサンドバッグにした。まぁ、自分も殴った側にいるのだから偉そうなことは言えない。この件について、株
Vault参考訳 | Pocketstudio.jp log3
HashiCorp から新しいツール Vault がリリースされました。credentialや機密情報的なものを管理するためのツール。例によって参考訳です。変なところありましたら、ご指摘いただけると助かります。 Vault – HashiCorp https://hashicorp.com/blog/vault.html ※今回も一応書いておきますと、本blogでの投稿は私個人の意志によるものであり、所属する組織の意見を代表するものでもなく、仕事でもなく、誰からの指示をうけているわけでもなく、すべて興味本位であり、ぶっちゃけ好き勝手に書いています。これまでも、これからも。 ■ Vault 機密情報を管理するツール 今日私達は Vault という安全な機密情報の管理と暗号化データ転送を行うツールを発表します。credential や API 鍵の保管から、ユーザ・サインアップ用のパスワードの
HashiCorp社が出したVaultとはどういうものなのか - 理系学生日記
HashiCorp 社から、新たなソフトウェアである Vault by HashiCorp がリリースされました。 - HashiCorp Blog: Vault この Vault について、Getting Started を一通り実施した後に Docs の一部を確認してみたので、簡単にその内容をまとめてみます。 Vault とは何なのか Vault を一言で言うと、機密情報(Secret) を管理するツールです。 これだけ IT が広がっている現在、機密情報の範囲も広がり続けており、データベースにアクセスするためのユーザ/パスワードや、連携するシステムの API キー等、多岐に渡ります。こういった情報、おまえのところのシステムではどう管理してた？XML に生で書いてる、あるよねそういうの。jdbc.properties に直書き、うんうんわかるわかる。ちょっとがんばったら crypt で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita
