GitHub - FiloSottile/mkcert: A simple zero-config tool to make locally trusted development certificates with any names you'd like.You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
SSL and TLS Deployment Best Practices
Version 1.6-draft (15 January 2020) SSL/TLS is a deceptively simple technology. It is easy to deploy, and it just works--except when it does not. The main problem is that encryption is not often easy to deploy correctly. To ensure that TLS provides the necessary security, system administrators and developers must put extra effort into properly configuring their servers and developing their applica
SSL/TLSサーバ証明書、コードサイニング証明書 | 国内最安値DigiCert（デジサート）正規代理店
Forward Secrecyとは 過去の秘密データを守る 暗号化されたデータの盗聴 盗聴されたデータは、SSLで暗号化されていればそのままでは解読されることはありませんが、暗号化する際に使用した鍵が入手できた時のためにそのまま保存されている可能性はあります。 NSA・米国国家安全保障局による盗聴疑惑が話題になりましたが、国家機関であれば暗号化された全インターネットデータも保存することが可能です。 実際に、暗号化鍵が露呈される事件も起こっています。2014年にも、有名なOpenSSLに重大な脆弱性（Heartbleed）が見つかっています。（HeartbleedについてはOpenSSL Heartbleed（心臓出血）脆弱性へのDigiCertの対応をご参照ください。） このような事態が起こった場合、バグフィックスを行ったうえで新しい秘密鍵を設定すれば、それ以降の通信データの安全性は確保で
暗号スイートの暗号強度と、公開鍵のビット数の設定、及びRSAとECDHEでサーバ負荷の比較 - Apache 2.4系でHTTP/2対応サーバを構築してみるテスト。
見ず知らずの他人同士が、リーズナブルな計算量で、秘密の通信を行うためには、公開鍵暗号と秘密鍵暗号を組み合わせる必要があります。 この暗号の組み合わせのことを「暗号スイート」と呼びます。 OpenSSLには、多くの暗号スイートが用意されています。どの暗号スイートを選べばいいのか、迷ってしまうと思います。 そして、暗号スイート全体としての暗号強度は、公開鍵の強度も関係してきます。 ここでは、総当たり攻撃の耐性を基準に、暗号スイートと公開鍵の決め方を説明していきます。 以下、私の独断と偏見ですが、なぜGoogleやFacebookが、ECDHE(256bit)-ECDSA(256bit)-AES(128bit)の暗号スイートを使用するのか、ご理解いただけると思います。 併せて、Apache Webサーバ(httpd)のECDHEのビット数の変更方法(P-256, P-386)も、説明しています。
理解してるつもりの 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
CertM という TLS 証明書作成ツール
https://github.com/ehazlett/certm という TLS 証明書作成ツールを見つけたのでメモっておく OpenSSL での証明書作成については https://jamielinux.com/docs/openssl-certificate-authority/index.html がとても良く出来ているのであまりこのツールに頼ることはない気もするがテスト用の証明書をさくっと作りたい場合には使うかもしれない （docker を実行可能な環境であれば docker run ... と実行するだけで使えるっていうのは配布方法としても悪くないですね） まずはヘルプを見てみる $ docker run --rm ehazlett/certm -h NAME: /bin/certm - certificate management USAGE: /bin/certm [glo
OpenSSL Certificate Authority — Jamie Nguyen
OpenSSL Certificate Authority¶ This guide demonstrates how to act as your own certificate authority (CA) using the OpenSSL command-line tools. This is useful in a number of situations, such as issuing server certificates to secure an intranet website, or for issuing certificates to clients to allow them to authenticate to a server.
前方秘匿性 (forward secrecy) をもつウェブサイトの正しい設定方法
前方秘匿性（forward secrecy）とは、以下のような性質を指します。 公開鍵暗号の秘密鍵のように、比較的長期に渡って使われる鍵が漏えいしたときでも、それまで通信していた暗号文が解読されないという性質 鍵が漏れることも想定せよ――クラウド時代における「楕円曲線暗号」の必然性 - @IT 鍵が攻撃者や諜報機関など第三者の知るところとなった場合でも、それまで通信していた暗号文が解読されないようにしないといけない、という考え方とともに、最近 HTTPS を利用するウェブサイトにおいても導入が求められるようになってきた概念です。 前方秘匿性を満たすウェブサイトの設定方法については、TLSの暗号化方式をECDH_RSAあるいはECDHE_RSAに設定すれば良い、と述べている文献が多いです。 ですが、ほとんどのウェブサーバにおいて、それは誤りです。 なぜか。 通信を暗号化する鍵（セッション鍵）
自堕落な技術者の日記 : 将来Google ChromeがSSL証明書のオンライン失効検証をやめて独自の失効情報プッシュを行うという困った話 - livedoor Blog（ブログ）
CRLSetではZIP復元処理が2回あるのでCRLのASN.1の 処理コストと比較して5分5分といったところだろうか。 ちなみに、現在プッシュしているCRLSetはたった35のルートCA,中間CAしかサポートしていない。 ImperialVioletのブログの主張のおかしな点 「オンライン失効検証ができない場合様々な問題が起きる」として幾つか問題点を述べている。 「"captive portal"(ホテルのインターネットなどでウェブブラウザで認証してから ネットが使えるようになる仕組みの事)などでは接続前はオンラインの失効検証が できない」としているが、その時点ではホテルのサービスの認証のページしか繋がる 必要が無いのであまり大きなリスクとも思えない。特定の問題なので 別に解決策もあると思う。 「認証局のCRLを提供するリポジトリやOCSPレスポンダがダウンした場合、 そこが単一障害点にな
SSL／TLS（Part.1）
まず、目立つのは下半分に横たわるReocord Protocolである。Record Protocolより上位にある各プロトコルは、Record Protocolを介して対向する通信相手とデータをやり取りする。Record Protocolは前述のように圧縮／暗号化を行っているので、これら上位プロトコルでの通信内容は原則として暗号化されることになる。 その際、Record Protocolでは、図中の「利用中の暗号化パラメータ」と書かれている情報に基づいて暗号化の処理を行っている。この「利用中の暗号化パラメータ」には、具体的に言えば、使用する圧縮アルゴリズムや暗号アルゴリズム、また暗号化／復号で使うキーなどが含まれる。いわば「圧縮／暗号化のルール」とでも考えれば分かりやすいだろう。 では、この「利用中の暗号化パラメータ」は、どうやって取り決めるのだろうか。「圧縮／暗号化のルール」である以上
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - icing/mod_md: Let's Encrypt (ACME) in Apache httpd