無料の SSL 証明書が得られる ZeroSSL を使ってみた
はじめに 皆さんは ZeroSSL を知っていますか？個人でウェブサイトを運営している皆さんであれば、多くの方は Let's Encrypt を利用されていると思います。 https://letsencrypt.org/ja/ もちろん僕も使っています。僕の様なエンジニアの方であれば SSL の仕組みもおおよそ理解もしているし、コマンドラインの実行方法も知っておられるのでウェブサイトの SSL 証明書を取得する事もそれほど難しい事ではないでしょう。 しかしそれほど詳しくない方が certbot の様なコマンドを使って SSL 証明書を発行するのは割と難しい事です。そこでご紹介したいのが ZeroSSL です。 https://zerossl.com/ ZeroSSL とは ZeroSSL もまだあまり名前が知られていないせいか、Google 検索で「ZeroSSL」を検索すると「ZeroS
オレオレ証明書を使い続ける上場企業をまとめてみた - megamouthの葬列
あるいは私たちがPKIについて説明し続けなければいけない理由 Web屋のなくならない仕事の一つに「SSL証明書とPKIについて説明する」というのがある。 世の中のサイトはだいたいhttps://というアドレスでつながるように出来ていて、httpsでつながるということは何らかのSSL/TLS証明書が必要だということだ。（さもなければchromeがユーザーに不吉な警告を発することになる） 証明書が必要になる度、同じ質問が繰り返される。「なんか全部値段が違うけど、どの証明書（ブランド）がいいの？」と。そして私たちは毎回困ってしまう。 エンドユーザーの立場で言えば、証明書が有効でありさえすれば、無料のLet's Encryptでも21万円するDigiCertグローバル・サーバID EVでも、Webサイトの利便性は何も変わらない。私たちWeb制作業者の立場でも、代理店契約でもしない限り、証明書そのも
J-STAGEがFirefoxでのアクセスを遮断、日本の電子ジャーナルが世界から不可視となった日｜Guest｜note
科学技術振興機構（以下JST）の運営する「J-STAGE」は、国立情報学研究所が運営する「CiNii」と双璧を成す、日本の電子ジャーナルプラットフォームである。それが2018年12月12日、Firefoxからのアクセスが不可能となった。 試しにFirefox 64でアクセスしてみたところ、確かにページ読み込みエラーとなり、コンテンツを表示することができなかった。サーバ証明書のエラーではないため例外を許可して続行することもできない。完全にFirefoxでのアクセスが遮断された格好だ。 翌日13日になってTwitterで原因の考察が始まり、J-STAGEの対応する暗号スイートに問題があることが判明する。 原因はJ-STAGEのTLS仕様違反J-STAGEはセキュリティ強化のため、2018年12月12日にTLS 1.2への切替とTLS 1.0/1.1の無効化を行うことを予告していた。これが影響し
自堕落な技術者の日記 : HPKP(HTTP Public Key Pinning)公開鍵ピニングについて考える - livedoor Blog（ブログ）
もくじ 1. はじめに 2. HPKPが生まれた背景 3. HPKPの仕組み 4. ピンの設定の考察 4.1. ピンの値の取得方法 4.2. 証明書チェーンに一致するピンの選択 4.3. 証明書更新とHPKPヘッダの設定変更の運用方法 4.4. バックアップピンという名前のイケてなさ 4.5. CA鍵のバックアップピンのオススメの値 4.6. 証明書チェーン中で複数ピンをつけても意味はない 4.7. 同じCA証明書にPinし続ける場合の課題 4.8. 2つのCA証明書にPinする場合の課題 4.9. max-ageのオススメ値を考える 5. HPKPはどの程度使われているのか 6. 今のHPKPの何がいけなかったのか 7. おわりに 8. (参考) HPKP関連の勉強になるリンク 9. 追記 9.1. 追記(2017.02.26) HPKPのブラウザサポート状況 9.2. 追記(2017.
中国最大の認証局「WoSign」が証明書発行日改竄などを行っていたとしてFirefoxがブロックの方針
by Eljay 中国最大級の認証局「沃通(WoSign)」がニセ証明書を発行していた問題で、ウェブブラウザの1つ・FirefoxがWoSignの証明書をブロックする方針を固めました。 WoSign and StartCom - Google Docs https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/ Firefox ready to block certificate authority that threatened Web security | Ars Technica http://arstechnica.com/security/2016/09/firefox-ready-to-block-certificate-authority-that-threatened-we
中国最大級の認証局「WoSign」がニセの証明書を発行していたことが判明
by Barney Moss 無料でSSL証明書を発行してくれることで、多くの自宅サーバーユーザーに重宝されている中国最大級の認証局「沃通(WoSign)」が、「偽物の証明書」を大量に発行していたことが明らかになりました。 The story of how WoSign gave me an SSL certificate for GitHub.com | Schrauger.com https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com Thoughts and Observations: Chinese CA WoSign faces revocation after possibly issuing fake certificates of Github,
SSLの脆弱性で日本の大手サイトを含む全世界1100万以上のHTTPSサイトが攻撃を受け得ると判明
SSL/TLSによって通信を暗号化しているHTTPSサイトに簡単に攻撃される脆弱性があることがセキュリティ研究者によって発表されました。この脆弱性をついた攻撃「DROWN」を受ける可能性があるサイトには、毎日新聞、任天堂、はてな、LINEなどの日本の大手サイトも含まれています。 DROWN: Breaking TLS using SSLv2.pdf (PDFファイル)https://drownattack.com/drown-attack-paper.pdf DROWN Attack https://drownattack.com/ 「Decrypting RSA with Obsolete and Weakened eNcryption(DROWN)」はSSLv2に含まれる脆弱性で、この脆弱性を悪用されるとクロスプロトコル攻撃によってTLSセッションの暗号化が解除(復号)されて通信が傍受
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.
Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes
Intro 先日 #http2study で mozilla の Richard Barnes が Let's Encrypt について話してくれました。 資料: Let's Encrypt Overview この資料の翻訳 はしたのですが、いらなくなってしまったので供養もかねてこのプロジェクトのモチベーションと、 Web でおこっている HTTPS 推進のたどる道について、資料を補足しつつ紹介します。 結論から言うと Let's Encrypt はもちろん ACME プロトコル についても是非知っておくと良いと思います。 HTTPS の問題 すでにこのブログでも紹介しているように、 Web における HTTPS の重要性は増し、それの普及を後押しする活動が各所で進められています。 HTTPS 化する Web をどう考えるか よく言われる盗聴防止を始め、暗号化を行うことで防げる問題は多くあ
OpenSSLの脆弱性(CVE-2015-1793)によるAltチェーン証明書偽造の仕組み - ぼちぼち日記
TL;DR やっぱり書いていたら長文になってしまいました。あまりちゃんと推敲する気力がないので、変な文章になっているかもしれません。ご了承いただける方のみお読みください。 1. はじめに 昨晩未明にOpenSSL-1.0.2d, 1.0.1pがリリースされました。事前に予告されていた通り深刻度高の脆弱性CVE-2015-1793が修正されています。Advisoryを見ると、この脆弱性がiojs/Nodeに影響があるということが判明したので直ちにiojs/Nodeのアップデートを行い、今朝未明に無事脆弱性対応版をリリースしました。 今回が初めてではありませんが、深夜に日欧米のエンジニアがgithub上で互いに連携しながら速やかにセキュリティ対策のリリース作業を行うことは何回やってもなかなかしびれる経験です。時差もありなかなか体力的には辛いものがありますが、世界の超一流のエンジニアと共同でリア
atc proceedings
On the Release of CRLs in Public Key Infrastructure Chengyu Ma1 Beijing University machengyu@pku.edu.cn Nan Hu, Yingjiu Li Singapore Management University hunan,yjli@smu.edu.sg Abstract Public key infrastructure provides a promising founda- tion for verifying the authenticity of communicating par- ties and transferring trust over the internet. The key issue in public key infrastructure is how to p
TLSの普及へサーバ証明書を無料発行、MozillaやCiscoが認証局を創設
「Let's Encrypt」のサービスでは誰でもワンクリックで簡単に自分のドメイン用のベーシックなサーバ証明書を入手して実装できるようにする。 インターネット上の通信を暗号化するTLSの普及を目指し、手軽に実装できるサーバ証明書を無料で発行する認証局（CA）の「Let's Encrypt」が、MozillaやCisco Systemsといった大手のバックアップで創設された。 TLSを利用するためには、通信相手のサーバが本物であることを認証するための証明書をサーバ運用者が取得する必要がある。しかしこうした証明書は一般的には有料で、正しくインストールするのが難しく、アップデートにも手間がかかるとLet's Encryptは指摘する。 こうした問題を解決するため、Let's Encryptのサービスでは誰でもワンクリックで簡単に自分のドメイン用のベーシックなサーバ証明書を入手して実装できるよう
SSL/TLS, SSH で利用されている公開鍵の多くが意図せず他のサイトと秘密鍵を共有している問題 – IIJ Security Diary
インターネット上の IPv4 アドレスを広範囲にスキャンして、SSL/TLS, SSH で利用されている公開鍵証明書および DSA 署名を収集したところ、SSL/TLS では5.57% (714,243アドレス)、SSH では9.60% (981,166アドレス) が、意図せず他のサイトと秘密鍵を共有していることが報告されています。その原因は機器出荷時のデフォルト鍵を利用しているケースと、鍵生成時に擬似乱数生成モジュールのエントロピー不足であることが指摘されています。善意で提供されているオンライン鍵チェックサービスにより公開鍵が脆弱かどうかチェックできますので、必要な場合には早急に対策を実施してください。 USENIX Security Symposium は、毎年実践的な研究発表が行われる場で、本年は8月6日から10日にかけて、米国 Redmond にて他のワークショップとともに開催され
華麗なる因数分解:FREAK攻撃の仕組み - ぼちぼち日記
1. はじめに ちょうど今朝 OpenSSLをはじめとした様々なTLS実装の脆弱性の詳細が公表されました。 この InriaとMSRのグループは以前からTLSのセキュリティに関して非常にアクティブに調査・検証をしているグループで、今回も驚きの内容でした。 このグループは、TLSのハンドシェイク時の状態遷移を厳密にチェックするツールを開発し、様々なTLS実装の脆弱性を発見・報告を行っていたようです。 特にFREAKと呼ばれるOpenSSLの脆弱性(CVE-2015-0204)に関しては、ちょうど修正直後の1月初めに Only allow ephemeral RSA keys in export ciphersuites で見ていましたが、具体的にどのように攻撃するのかさっぱりイメージできず、あのグループだからまた超絶変態な手法だろうが、まぁそれほど深刻じゃないだろうと見込んでいました。 今回
SSL証明書を発行する企業が証明書を偽造する悪質なアドウェア「Privdog」を販売していたことが判明
COMODO Internet SecurityなどのPC向けセキュリティツールの開発や、SSL証明書の発行を行うComodoが販売していたソフトウェアの「Privdog」は、Lenovo製PCにプリインされているアドウェア「Superfish」よりも悪質なアドウェアで、HTTPSのセキュリティを完全に破壊してしまう危険性があるということが、ドイツ人ジャーナリストのHanno Böckさんのブログ内で明かされました。 Comodo ships Adware Privdog worse than Superfish - Hanno's blog https://blog.hboeck.de/archives/865-Comodo-ships-Adware-Privdog-worse-than-Superfish.html Lenovo製のノートPCにプリインストールされているソフトウェア「V
POODLE脆弱性がSSL 3.0からTLS 1.0 / TLS 1.1に拡大
2014年10月15日、「お客様への重要なお知らせ」にてご報告した『SSL 3.0に関する脆弱性について (Padding Oracle On Downgraded Legacy Encryption)』では、SSL 3.0プロトコルにのみ影響があるとされていました。しかし、このたび一部のTLS 1.0 / TLS 1.1においても、SSLで保護されたウェブサイトとブラウザの間で、ハッカーの通信傍受や暗号解読が可能であることがわかりました。 TLSパケット内で利用されているパディング構成を適切にチェックしていない実装がされている場合、この脆弱性の影響を受けます。今のところ、F5ネットワークスとA10ネットワークスのロードバランサでTLS接続をハンドルしているウェブサイトで、この脆弱性が発見されています。 より技術的な知見はGoogleセキュリティエンジニアAdam Langleyの投稿『T
意外と多い？問い合わせフォームの不完全な暗号化
暗号化の表示を確認 A社の商品を購入しようか迷っていたBさん。購入にあたり疑問点があったため、A社に問い合わせました。A社はホームページを持っており、そこには問い合わせフォームがありました。問い合わせの内容を記入しようとしたBさんは、そこに書かれてある説明文に目を通しました。 そこには、「お客様の個人情報保護のため、SSLを用いた暗号化通信に対応しています」という文言がありました。確かにアドレス欄を見ても「https」で始まっており、鍵マークも表示されていました。 入力内容の確認 Bさんは安心し、自分の名前と返信先のメールアドレス、質問内容を記入して送信ボタンを押しました。送信は問題なく完了したようで、「あとはA社からの回答を待つだけ」と思った次の瞬間、メールが届きました。 送信元はA社のアドレスで、「返信不可」の文字とともに、内容を確認するメールでした。そこにはBさんの名前と、送信した問
自堕落な技術者の日記 : Internet Week 2014パネルで話しそびれたネタ2: イントラ内でSSLサーバー設定を確認するツールsslaudit - livedoor Blog（ブログ）
先週のInternet Week 2014でHTTPSサーバー設定のセッションのパネルパネルで言えなかった事の第二弾です。 自分のサイトが公開サイトである場合にはQualys SSLLabsのサイトを使って外部からSSLの暗号スイートの設定を確認すればよいんですが、イントラ内の場合には厄介ですよね。パケットキャプチャで調べるわけにもいかないし、OpenSSLのs_clientで暗号スイート一つ一つチクチク調べるのは面倒だし。 そんな時、クライアント側にWindowsが使えればwww.g-sec.luで公開しているsslauditというツールが便利です。 検査対象のサーバー(IPアドレスでも可)とポート(デフォルトでは443)を指定して、「Start」ボタンを押すだけです。利用可能なものだけを表示する場合には「Display supported ciphers」をチェックしてからスタートする
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
システム会社の一台のWebサーバー（Nginx）でのSSL証明書の更新作業の見積もりが20万円でした。ファイルをアップロードして再起動するだけですよね？ぼったくりだと思いますか？
SSL ハンドシェイクの裏側 証明書失効確認メカニズム SSL サーバ証明書が情報漏えいに強い理由 - Symantec