Neverbleed - RSAの秘密鍵演算を別プロセスに分離する話
機能毎にプロセスを分割し、それらを別個の権限のもとで実行することで、脆弱性があった場合の影響を抑え込むというのは、一定以上の規模をもつプログラムでは、しばしば見られるデザインパターンです。 qmailは、そのような設計がなされたメール配送デーモンとして名高いですし、OpenSSHもまた、認証プロセスと通信プロセスを分離することで、外部との通信を担当するコードにバグがあったとしても、ルート権限が奪われないように設計されています（参照: Privilege Separated OpenSSH）。 一方で、OpenSSLにはそのような権限分離は実装されていません。Heartbleedの際にサーバの秘密鍵が漏洩したのも、秘密鍵の取り扱いと、その他の通信の取り扱いを同一のメモリ空間の中で行っていたからだと考えることができます。 ないのなら、自分で作ればいいじゃない…ということで作りました。それが、N
サービスごとに異なるパスワードを使い分ける方法 - kazuhoのメモ置き場
最近、パスワードの使い回しをしているユーザーに対する攻撃が出回るようになってきています (参照: パスワード攻撃に対抗するWebサイト側セキュリティ強化策 | 徳丸浩の日記) が、マスタパスワードからサービスごとに異なるパスワードを自動生成するのが簡単な対策ですよね。 プログラマなら（もしくはコマンドライン操作に慣れているのなら）、こんな感じでできるかなーと思います。 $ perl -MDigest::HMAC_SHA1 -wle 'print Digest::HMAC_SHA1->new($ARGV[0])->add($ARGV[1])->b64digest' "my-master-password" example.com Mau83v+ml6dRViOZhcRdHM0NXzY $HMAC 関数にマスターパスワードとサービスのドメイン名を食わせて、その出力をサービス専用のパスワードにす
InfoQ: HTTPSコネクションの最初の数ミリ秒
ほとんどの人がHTTPSとSSL (Secure Sockets Layer) を結びつけて考えます。SSLは1990年代半ばにNetscape社が開発した仕組みですが、今ではこの事実はあまり正確でないかもしれません。Netscape社が市場のシェアを失うにしたがって、SSLのメンテナンスはインターネット技術タスクフォース(IETF)へ移管されました。Netscape社から移管されて以降の初めてバージョンはTransport Layer Security (TLS)1.0と名付けられ、1999年1月にリリースされました。TLSが使われだして10年も経っているので、純粋な"SSL"のトラフィックを見ることはほとんどありません。 Client Hello TLSはすべてのトラフィックを異なるタイプの"レコード"で包みます。ブラウザが出す先頭のバイト値は16進数表記で0x16 = 22。 これは
妻に公開鍵暗号を教えてみた - 西尾泰和のはてなダイアリー
何気なく放送大学をつけていたら公開鍵暗号の話をしていた。 妻「この話、何度聞いてもわかんないのよね」 僕「え、どこがわからない？どこまではわかってる？」 妻「平文はわかるけど、鍵を共有するとか秘密にするとか、署名するとかがよくわからない」 僕「あー、鍵に例えているのが逆効果なのか」 「鍵」をNGワードに指定 僕「じゃあ『鍵』という言葉を使わずに説明してみよう。暗号って『平文を暗号文に変換する方法』で伝えたい文章を暗号文に変えて送り、受け取った人はそれに『暗号文を平文に戻す方法』を使って元の文章を得るわけだ。その目的は、途中の通信文が敵に取られたりしても通信の内容がバレないようにするため。」 妻「うん」 僕「昔の暗号化の方法は、片方の方法がわかるともう片方の方法も分かった。例えば『アルファベットを後ろに1個ずつずらすと平文に戻せます』って教えてもらったら、『なるほど、前に1個ずつずらせば暗号
Time-based SQL Injectionは意外に実用的だった
このエントリでは、Time-based SQLインジェクション、すなわち時間差を利用したSQLインジェクションが意外に実用的だったという報告をします。デモ映像ありです。 はじめに Time-based SQL Injectionという攻撃があります。これはブラインドSQLインジェクションの一種で、ある条件の場合に一定時間（例えば5秒）スリープし、そうでない時との応答時間の差で情報を盗もうというものです。1回のHTTPリクエストで1ビットの情報が得られるので、それを積み重ねることによって、いくらでも情報を盗めるはずです…理論的には。 しかし、「理屈はそうでも、時間が掛かりすぎるよね」ということで、深くは追っかけていませんでした。SQLインジェクションの検査には有効でも、悪用としての実用性はあまりないと考えていたのです。 きっかけ きっかけは、以下のYahoo!知恵袋に以下の質問です。 SQL
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について The sad state of sysadmin in the age of containers コンテナー時代のシステム管理者の惨状 システム管理は惨劇に見舞われている。現状は悲惨だ。 筆者は昔気質のシステム管理者に不満はない。システムの稼働を維持し、アップデートし、アップグレードする方法を知っている者達だ。 この憤りは、コンテナーと構築済みVMと、それらがもたらす、「信頼」や「アップグレード」の欠如による悲惨な惨劇に対するものだ。 例えば、Hadoopを見てみろ。誰もHadoopをスクラッチからビルドする方法を知っているようには見えないぞ。依存性とバージョンとビルドツールが悲惨なほどに絡まりあっている。 この手のイケてるツールの中で、古典的なmake
クラウドを支えるこれからの暗号技術 - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズ・ラボの光成です。 私は先月のDevelopers Summit 2015で、「クラウドを支えるこれからの暗号技術」という講演をいたしました。そのとき、近いうちに詳細なテキストを公開する予定と申し上げました。その準備ができましたので報告いたします。 講演と同じタイトル『クラウドを支えるこれからの暗号技術』のpdfはgithubから取得できます。 2015/6/21追記。このテキストが秀和システムから出版されました。 表題の講演は、主に2000年に入ってから登場した新しい暗号技術の紹介がメインです。そのときのプレゼン資料は3月の時点で4万5千ビューを超えていて、デブサミ資料の中でもかなり上位に入る閲覧数のようです。技術者の暗号に関する関心が高いことを伺わせます。 しかし一般向けの暗号のテキストは、公開鍵暗号の一つであるRSA暗号やElGamal暗号ぐらいしか詳しい原理が記されていな
Security/Server Side TLS - MozillaWiki
The ordering of cipher suites in the Old configuration is very important, as it determines the priority with which algorithms are selected. OpenSSL will ignore cipher suites it doesn't understand, so always use the full set of cipher suites below, in their recommended order. The use of the Old configuration with modern versions of OpenSSL may require custom builds with support for deprecated ciphe
NginxでSSLの評価をA+にする手順
昨日 HTTPS 化した シャンプー評価サイト のSSL評価をA+にしました。 参考にしたのは下の記事 HTTPS on Nginx: From Zero to A+ (Part 2) - Configuration, Ciphersuites, and Performance - Julian Simioni この記事のNginx証明書設定をPOSTDさんが翻訳しているので、近いうちに詳しい訳は日本語で読めるかも。ここでは適当にかいつまんだ手順を書いておく。一部時間のかかるコマンドもあるけど、基本的に決まった設定書くだけなので時間はかかりません。（もちろんどういう意味なのか知っておくに越したことはない） SSLの評価計測について SSLサーバーのテストはQualys SSL Reportで確認します。 Nginxデフォルトの設定で計測したらCだった。 SSLv3 を無効にする SSLv3
CentOS6＋NginxでECDHEを有効にしてForward Secrecy取得までのメモ - 不意に何かを残すブログ
昨日は鍵共有を甘く見て爆死したためCentOS＋NginxのサーバーをWindows環境に対応させてみる。 RPMに慣れていた都合上、主なサーバーにCentOS6を使っている。 CentOS/RHEL6.4では2013年10月時点で、標準のOpenSSLは1.0.0、Nginxは1.0系が導入される。Nginxには公式リポジトリもあるが、openssl-1.0.0を前提にビルドされている。 これらはコミュニティサポートのあるRPMで提供されているものの、NginxでHTTPSサーバーを建てようとすると、TLSはv1.0 まで、対応cipherはDHE-RSA-AES-SHAまでになり、QualsysのSSLテストでは色々と指摘される。 問題点 既存のパッケージで対策不能なのは、TLS1.2対応（兼BEAST対策）とRSA鍵共有。 BEASTは未対策のブラウザがTLSv1.0以前のCBCモー
oss-security - Qualys Security Advisory CVE-2015-0235 - GHOST: glibc gethostbyname buffer overflow
Follow @Openwall on Twitter for new release announcements and other news [<prev] [next>] [thread-next>] [day] [month] [year] [list] Date: Tue, 27 Jan 2015 08:29:36 -0800 From: Qualys Security Advisory <qsa@...lys.com> To: oss-security@...ts.openwall.com Subject: Qualys Security Advisory CVE-2015-0235 - GHOST: glibc gethostbyname buffer overflow Qualys Security Advisory CVE-2015-0235 GHOST: glibc g
細かすぎて伝わらないSSL/TLS
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 「細かいと言うより長いよね」 はじめに こんにちは。ATS の脆弱性を発見した小柴さんや ATS に HTTP/2 の実装を行っている大久保さんと同じチームの一年目、匿名社員M さんからいじられている新人です。今回ありがたい事に、こういったすごい方々を含めモヒカン諸先輩方より「何か書かないの？」「いつ書くの？」という数々のプレッシャーお言葉をいただきました。 というわけで、SSL/TLS の Session 再開機能に関して書いていこうかと思います。 SSL/TLS は機密性、完全性そして真正性に対して安全な通信を行うための仕組みです。しかし、この仕組みは暗号技術を多用し特に接続において複雑なプロトコルを用い、Client, Se
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
JVNVU#98974537: OpenSSL に複数の脆弱性
影響を受けるシステムは脆弱性により異なりますが、OpenSSL 1.0.1、1.0.0、0.9.8 のすべてのバージョンが影響を受ける可能性があります。 2015年1月8日に OpenSSL Security Advisory が公開されました。アドバイザリの情報によると、下記の 8件の脆弱性が修正され、修正版の OpenSSL として、1.0.1k、1.0.0p、0.9.8zd をリリースしたとのことです。 深刻度 - 中 (Severity: Moderate) DTLS segmentation fault in dtls1_get_record (CVE-2014-3571) DTLS memory leak in dtls1_buffer_record (CVE-2015-0206) 深刻度 - 低 (Severity: Low) no-ssl3 configuration se
そこそこセキュアなlinuxサーバーを作る - Qiita
先日「サーバーのセキュリティ設定がなにすればいいかわからない」と相談をうけまして。 自分も初心者の時どこまでやればいいかわからず手当たりしだいにやって沼に入っていたのを思い出しながら自鯖構築したときのメモを元にまとめてみました。 注意 セキュリティ対策は用途や場合などによって違います。 自分で理解したうえで自己責任でおねがいします。 対象読者 Linuxのサーバーを建て慣れていない人 Linuxはある程度さわれる人(自分でパッケージを入れたり、サービスを止めたりできる) ラインナップ ☆は導入の重要度と導入の容易さから個人的偏見からつけた値です。 4つ以上が"最低限やること"だと思ってください。 sshd
Linuxをクラッシュさせられるバグが権限昇格のバグに進化した件 - ブログ - ワルブリックス株式会社
今月の初めに公表されていた、一般ユーザーが Linuxシステムをクラッシュさせてしまえるバグ CVE-2014-9090 が実は root権限の奪取にも使えることがわかり CVE-2014-9322 に進化しています。 CVE-2014-9090の日本語情報はこちら。 Linux Kernel の arch/x86/kernel/traps.c 内の do_double_fault 関数におけるサービス運用妨害 (DoS) の脆弱性 要するに、64bit版の Linuxでは管理者権限を持たない一般ユーザーが「わざと」システムをクラッシュさせてしまうことができるということです。対象となるのは x86_64用 Linuxカーネルの 今までの全てのバージョンです。 いま動いてるLinuxが 32bitか64bitかよくわからない場合は uname -m と入力して i686と出れば 32bit、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita
notes/security/macos-keychain.md at main · eoinkelly/notes
DoS攻撃からサーバーを守る、mod_dosdetector導入事例のご紹介 | Raccoon Tech Blog [株式会社ラクーン 技術戦略部ブログ]![DoS攻撃からサーバーを守る、mod_dosdetector導入事例のご紹介 | Raccoon Tech Blog [株式会社ラクーン 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/77d04c903b6ca44c55f5b77d4e45c47799d10b24/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2018%2F04%2Fe3abce2d.png)
SSL Server Test (Powered by Qualys SSL Labs)