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
websec-room.com - websec room リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
badssl.com
badssl.com 🎛Dashboard Dashboard 🎫Certificate expired wrong.host self-signed untrusted-root revoked pinning-test no-common-name no-subject incomplete-chain sha256 sha384 sha512 1000-sans 10000-sans ecc256 ecc384 rsa2048 rsa4096 rsa8192 extended-validation 🎟Client Certificate Certificate Downloads client client-cert-missing 🖼Mixed Content mixed-script very mixed mixed-favicon mixed-form ✏️HTTP h
NginxでのSSL設定の細かい意味 · GitHub
Clone via HTTPS Clone with Git or checkout with SVN using the repository’s web address. NginxでのSSL設定（もうちょっと詳しく） listen 443 ssl ssl on; nginxの確認 nginxをmakeするときに「–with-openssl=」オプションを使わずにsslに対応してあることを確認しておく。 $ `which nginx` -V 2>&1 | grep openssl $ （何も表示されないことを確認） 次にopensslのバージョン確認。 $ rpm -qa openssl $ openssl-1.0.1i-1.78.xxxxxxxx.x86_64 ※ 「xxxxxxx」はPlatform名。 バージョンが1.0.1i以上であることを確認しておく。 もしopensslのバ
SSL/TLSの基礎と最新動向
1. SSL/TLSの基礎と最新動向 セキュリティキャンプ 2015 2015年8月12日 IIJ 大津 繁樹 更新版資料の置場 http://goo.gl/cX1M17 Github Repo: https://goo.gl/vRLzrj 2. 自己紹介 • 大津 繁樹 • 株式会社 インターネットイニシアティブ • プロダクト本部 アプリケーション開発部サービス開発2課 • NodeJS Technical Committee メンバー • (主にTLS/CRYPTO/OpenSSLバインディングを担当） • IETF httpbis WG で HTTP/2相互接続試験等仕様策定に参画。 • ブログ： http://d.hatena.ne.jp/jovi0608/ 3. はじめに • TLS(Transport Layer Security)の仕組みについて学んでいただき ます。 •
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
Superfish/eDellRootが危険な理由 - めもおきば
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で
みずほ銀行のセキュリティ対策が酷すぎるのでまとめてみた - Windows 2000 Blog
目的のページにアクセスするには、アドレスバーの「https://www.mizuhobank.co.jp/〜」を「http://www.mizuhobank.co.jp/〜」に修正し（httpsの”s”を削除）、エンターキーを押してください。 https://www.mizuhobank.co.jp/〜は2014年11月27日よりご利用いただけなくなりました。 https://www.mizuhobank.co.jp/〜でブックマーク（お気に入り）に登録されているお客さまは、http://www.mizuhobank.co.jp/〜に登録先の変更をお願いします（httpsの”s”を削除してください）。 Firefox 18 で、SSL (https) ページ上で非 SSL (http) サイトのコンテンツ読み込みをブロックする設定が追加されました。ユーザのセキュリティを高めるため、これらの
自堕落な技術者の日記 : ChromeのSHA1証明書のアラート表示ポリシの問題点 - livedoor Blog（ブログ）
表を見ていただければわかる通り、Microsoft WindowsのSHA1移行ポリシに比べて、Chromeはかなりアグレッシブな設定になっており、開発版は2014年9月26日のアップデートから、安定版は2014年11月頃リリースの39から正常なHTTPS接続でないかのようなステータス表示となってしまいます。 今回のChromeのSHA1対応ポリシの問題点 今回のGoogle ChromeのSHA1証明書に対する対応計画は様々な問題があると考えていて、論点を整理したいと思います。 最も重要だと思うのが、ブラウザ毎にHTTPSのエラーや問題に対する表示の意味が異なってしまうという点です。今回のSHA1証明書の表示の計画がブラウザベンダー毎に異なるのはユーザが混乱することになり、良くなかったと思います。本来ならCA Browser ForumのBaseline Profileなどで、業界で意思
Google unveils independent “fork” of OpenSSL called “BoringSSL”
Google is releasing its own independently developed "fork" of OpenSSL, the widely used cryptography library that came to international attention following the Heartbleed vulnerability that threatened hundreds of thousands of websites with catastrophic attacks. The unveiling of BoringSSL, as the Google fork has been dubbed, means there will be three separate versions of OpenSSL, which is best known
Apple史上最悪のセキュリティバグか、iOSとOS XのSSL接続に危険すぎる脆弱性が発覚──原因はタイプミス？
Appleは21日、iOSのソフトウェアアップデート7.0.6をリリースした。 iOS 7.1が早ければ3月中旬にもリリースされるとみられていたが、SSL接続の検証に関して、半月以上も待つことができない重大なバグが見つかったためだ。 SSLとは、「ウェブサイトで入力する個人情報やクレジットカード情報などを暗号化し、安全に送受信する技術」（Symantec）だ。データを安全にやりとりするために利用されている非常に重要な技術となっている。 そして今回、クライアント（ユーザ側）とサーバ（ウェブサイト側）の間をSSL接続する際のプログラムに、「BASIC初心者でも一目で分かるようなミス」（Wired）が見つかり、修正されることになったようだ。ミスがあったのは、以下の部分。 Appleが公開しているソースコード 「goto fail;」が2行続けて記述されている箇所に注目してほしい。2行目の「got
Y!J API が止まった日 - GlobalSign の Root 証明書切れから学んだこと - OAuth.jp
昨日あたりから、Yahoo! Wallet や YConnect といった、Yahoo! Japan の API にアクセスできなくなったって人、ちらほらいるかもしれませんね。 僕もちょっとそういうケース見かけました。 なんか Yahoo! Japan がポカしちゃったの？とか、まぁ昨日まで健康に動いてたシステムが突然 Yahoo! Japan の API にアクセスできなくなっちゃったんだし、そらそう思うのもムリはない。 が、今回のケース、Yahoo! は全く悪くない！ プライバシーフリークはどうかと思うがな！！ では早速、今回起こったことを、振り返ってみましょう。 Yahoo! API にアクセスできなくなった Yahoo! Japan は、yahoo.co.jp 以外にも、CDN 用や API 用など、用途ごとにいくつかのドメインを持ってます。 今回止まったのは、その中の API 用
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
