タグ

SSLに関するatm_09_tdのブックマーク (26)

  • 【初心者向け】SSLサーバ証明書の選び方 | DevelopersIO

    証明書発行までの認証プロセス概要図 EVは細かい審査があるので、安心感がありますね。一方、ドメイン認証は実在確認していないので、運用者が実在するか確認していないですね。(認証局によってはドメイン認証でも実在確認しているところもあると思います。) SSLサーバ証明書のオプション 上記の種類の他にオプションがあります。 ワイルドカード 同一のドメイン配下の複数の異なるサブドメインに利用できるSSL証明書。 コモンネームに「*.example.com」を指定することで「www.example.com」や「api.example.com」、「admin.example.com」といったサブドメインが異なるサイトを1枚の証明書でカバーすることができる証明書です。 「*.example.com」で発行されている場合、「example.com」と「*.example.com」がSubject Alter

    【初心者向け】SSLサーバ証明書の選び方 | DevelopersIO
  • SSL/TLSとは何なんだ? 今こそ知ってもらいたいSSL/TLSのお話 〜 1回目 〜 SSL/TLSとは | さくらのナレッジ

    SSL/TLSとは何なんだ? 今こそ知ってもらいたいSSL/TLSのお話 〜 1回目 〜 SSL/TLSとは | さくらのナレッジ
  • SSL/TLS(SSL3.0~TLS1.2)のハンドシェイクを復習する

    以下順を追って説明します。 HelloRequest 相手にClientHelloを送信するよう促すメッセージです。送信しなくても構いません。 ClientHello ServerHello ClientHelloとServerHelloは、TLSのひとつめの肝です。後ほど説明します。 ServerCertificate サーバ証明書を送信します。中間CA証明書なども、ここで送ります。 ServerKeyExchange 鍵交換メッセージその1です。鍵交換はTLSのふたつめの肝で、これも後ほど説明します。 CertificateRequest クライアント証明書を送信するように促すメッセージです。クライアント証明書が必要な場合に送信します。何そのクライアント証明書って?と思った方は読み飛ばして構いません。 ServerHelloDone サーバからの送信終了を示すエンドマークです。 Cli

    SSL/TLS(SSL3.0~TLS1.2)のハンドシェイクを復習する
  • Let's encryptとSSL/TLSに関する誤謬 - Chienomi

    全く以て意味不明な誤謬がはびこっていた上に、やたら上から目線だったので、消火しておこうと思う。 そもそもSSL, TLSとは何か SSL/TLSは暗号化技術である。 SSL/TLSのデータ通信自体は対称暗号である。ただし、暗号化に利用する暗号鍵は使い捨てる。 Cipherはかなり色々使えるのだけど、だいたいはTriple DES (3DES)かAESが使われる。 その手順は <- HelloRequest -> ClientHello <- ServerHello <- ServerCertificate <- ServerKeyExchange <- ServerHelloDone -> ClientKeyExchange -> Finished -> ChangeCipherSpec <- Finished <- ChangeChiperSpec <-> Application Dat

  • AWS:無料でSSL証明書を取得する方法 - Qiita

    概要 先日公開した自分のサービスをhttps接続できるようにしたいと思いました。 SSL証明書は、どこが安くて信頼できるか社内の上司相談したところ、近くにいたインターン生が「AWSなら無料で発行できますよ。」とナイスなアドバイスをくれました。 さっそく調べて、SSL証明書を取得したのですが、ネット上には断片的な情報しかなく思ったよりも詰まったので、これから取得する方のために、わかりやすく画像で解説します。 前提 今回は、無料でSSL証明書が利用できるAWS Certificate Manager(ACM)を使います。 アジアパシフィック (東京)は、ELB(ロードバランサー)のみにACMを使用することができます。 なので、ELBを利用していないと、無料のSSL証明書を使うことができません。 ちなみに、ELBは有料で、デフォルトで月2000円くらい掛かります。 もし使用される方は以下に設定

    AWS:無料でSSL証明書を取得する方法 - Qiita
  • Herokuで2016/9/22から無料でSSL証明書を登録できるようになったので、既存のSSL Endpointから移行する方法 - Qiita

    Herokuで2016/9/22から無料でSSL証明書を登録できるようになったので、既存のSSL Endpointから移行する方法HerokuSSL 2016/9/22からHerokuのSSL利用が無料になった https://blog.heroku.com/ssl-is-now-included-on-all-paid-dynos#feedback 既存のSSL endpointを利用している場合でもダウンタイムなしに移行できるそうだ You can migrate from the SSL:Endpoint add-on to Heroku SSL with zero downtime. 残念ながら有料でHerokuを使っているユーザのみだが、月々7ドルのHobbyプランでも利用できる 既存の方法では月20ドル、年240ドル節約できるようになるのでけっこうお得 新方式のSSLのAddo

    Herokuで2016/9/22から無料でSSL証明書を登録できるようになったので、既存のSSL Endpointから移行する方法 - Qiita
  • DMM inside

    アニメ初の快挙!海外アニメ賞を受賞した『スキップとローファー海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏

    DMM inside
  • 5分でわかる正しい Web サイト常時 SSL 化のための基礎知識

    Web サイトを常時 SSL 化する場合に、最低限知っておかなければならない知識や、注意点、実際の設定方法まで、ひと通りまとめてみました。メリットやデメリット、証明書の種別からリダイレクト設定などについても解説しています。 HTTPS をランキングシグナルに使用しますと Google が公式に発表したあたりから、Web サイトの SSL 対応、特に Google が推奨している Web サイトをすべて HTTPS で配信する、所謂 「常時 SSL 化」 についての話を聞いたり、実際にお客様から相談されたりするケースが増えてきました。 そこで、いい機会だしその辺に関する情報をまとめておこうかな~ と思って書いてみた、恒例の (?) 5分でわかるシリーズ。書き終わって見たところ絶対に 5分じゃ無理っていう文章量になっててどうしようかなぁとも思ったんですが、気にせず公開してみます。 常時 SSL

    5分でわかる正しい Web サイト常時 SSL 化のための基礎知識
  • SSLで保護されていないページにログインフォームが存在するサイトについて

    OWASPというWebアプリケーションのセキュリティに関するガイドラインを公開している団体があります。その指針によれば The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbit

    SSLで保護されていないページにログインフォームが存在するサイトについて
  • WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる

    OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO

    WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
  • “オレオレSSLサーバー証明書”が招く、思わぬリスクとコスト:日経 xTECH Active

    資料の紹介 企業のホームページや電子商取引などのサイトでは、SSL(Secure Sockets Layer)を使ってセキュリティを確保する必要がある。一般的には信頼性担保のため、第三者の認証ベンダーが発行する有償のSSLサーバー証明書を購入して利用することになる。だが、社内向けのイントラネットサイトに対しては、自己署名のいわゆる“オレオレ証明書”を代替手段として利用してはいないだろうか。 内部の従業員のみがアクセスするため、自己署名証明書を利用すれば、事実上費用を全くかけずに十分な保護が得られると考えられることが多い。だが、結果的にリスクを高め、コストを高額にしているケースも多いことはあまり知られていない。 資料は、自己署名証明書と第三者認証の証明書を比較しながら、自己署名のSSLサーバー証明書で発生する真のTCOを解説。信頼できる第三者の認証局を利用することが、実はコスト効率の良い方

    “オレオレSSLサーバー証明書”が招く、思わぬリスクとコスト:日経 xTECH Active
  • httpsだからというだけで安全?調べたら怖くなってきたSSLの話!? - Qiita

    課題 サイトをを立ち上げるときに当然のごとくSSL証明書をベンダーから購入して設置していたが、いざセキュリティ診断等でチェックしてもらうとSSLについての指摘を何件か受けてみた。なんでだろうと思いながらも、さらに最適なSSL設定は?と聞かれてそういえばあまり昔から手を入れたことなかったなと思い調べてみた SSL通信が確立するまでの概要フロー SSL通信について再度おさらい Nginxを元にしたSSLの設定 nginxのHTTPS サーバの設定を参考に、たった2行だけどSSLを考えてみる。書き方は違えどもapacheも概念は一緒のはず。

    httpsだからというだけで安全?調べたら怖くなってきたSSLの話!? - Qiita
  • HTTP/2.0のALPN利用に伴うSSL負荷分散装置の不具合にご注意下さい - ぼちぼち日記

    1. はじめに、 ただ今IETF-88@バンクーバーの開催が真っただ中です。スノーデン事件の余波もあり、インターネット技術(特にセキュリティ関連)の議論は熱くなっています。 ちょうど今朝未明(バンクバーでは11/5朝)に HTTP/2.0の標準化を進める httpbis ワーキンググループとセキュリティエリアの合同セッションが開催されました。合同セッションでは、ヘッダ圧縮技術(HPACK)のセキュリティや、HTTP接続(HTTPSではない)で通信の暗号化を行ったらどうか、といった興味深い議論が行われました。このうち将来HTTP/2.0の展開に重要な ALPN(Application Layer Protocol Negotiation) は、このミーティングで最終的な仕様を確定させる段階での議論でした。議論の中で、ALPNの導入によってブラウザから既存の実サービスへの接続に(少なからず)影

    HTTP/2.0のALPN利用に伴うSSL負荷分散装置の不具合にご注意下さい - ぼちぼち日記
  • スノーデン事件の裏で起きていたSSL秘密鍵を巡る戦い:Geekなぺーじ

    今月7日から9日にアリゾナ州で開催されたNANOG 59で、Ladar Levison氏がFBIにサービス全体のSSL秘密鍵を要求された話が公開されていました。 Ladar Levison氏が運営していた、Lavabitという電子メールサービスはスノーデン事件に関連して突如8月8日に閉鎖されています。 閉鎖時には詳細が書かれておらず、様々な憶測が語られていましたが、世界中から多数のネットワークエンジニアが集まるNANOGで、その一部始終が語られました。 この発表は、NANOG 59が開始される前の週に、裁判所が調査対象の氏名以外を機密解除したことによって実現しています。 インターネット上で提供されているサービス事業者にSSL秘密鍵を提出させ、かつ、その事実の公表が違法行為となるようにされてしまっている一方で、こういった内容を公的に語れるように裁判所で戦って、実際にそれを勝ち取るというのは凄

  • SSL証明書の各種確認コマンド | DevelopersIO

    よく訓練されたアップル信者、都元です。 実は個人的に、最近までSSLサーバ証明書というものにロクに触れたことがなかったのですが、先日CloudFrontがSSLに対応したのをうけて、格的に触ってみました。 ご存知の通り、SSL証明書は暗号や電子署名等の技術を利用した仕組みです。その昔、PDFの暗号化処理を実装したことがあるんですが、暗号処理関連の動作確認というのは非常に厄介なものです。暗号文を複号化するにあたって、自分が設定したパスワードで復号できない、ということは暗号化処理または復号化処理に間違いがあることになるわけですが、どこがどのように間違っているのか、追い掛けるのは事実上不可能です。(むしろ、分かったら暗号としてヤバいですね) さて、SSLサーバ証明書では、主に「秘密鍵(PEM)」「証明書署名要求(CSR)」「証明書(CER)」という3つのファイルを扱います。PEMを作成した後、

    SSL証明書の各種確認コマンド | DevelopersIO
  • なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改

    完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを1往復させないといけないのである。パケットの往復

    なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
  • もう二度とハマらない、SSL証明書の設定 - komagataのブログ

    この業界10年いて何度も!何度も!やってるのに!また! ・・・またSSLの設定で2時間ハマってしまった。 おれの怒りが有頂天になった。 もはや俺に残された手は手順を刺青として彫る以外・・・。 その前に最後のあがきとしてブログに残してみます。(何度となくWikiに残してるのに、それなのにハマるのです。) CentOS 5.2 privateキー作成。 openssl genrsa -des3 -out /etc/pki/tls/private/example.com.key 1024 パスワード削除版privateキー作成。 openssl rsa -in example.com.key -out example.com-nopass.key キーからcsr作成。 openssl req -new -key /etc/pki/tls/private/example.com.key -out

  • SSL is not about encryption

    これはTroy Hunt氏によるSSL is not about encryptionの和訳である。@ten_forward氏による翻訳もあるが訳がわかりづらいので、ほとんど参考にせずに翻訳し直した。 SSL is not about encryption. は The basic purpose of SSL is not encryption. のように訳す。同様な文例に Copyright is not about copying. がある。@ten_forward氏による「SSLは暗号化のためのものではありません」は誤訳である。ここでは「主目的ではない」と訳す。 SSLの主目的は暗号化ではない SSLの主目的は保証することである。サイトが物であることにある程度の信頼性を与えることで、データの送受信を行う際にデータが横取りされることも改ざんされることもなく意図した相手に届くと確信で

    SSL is not about encryption
  • Private Presentation

    Private content!This content has been marked as private by the uploader.

  • Webサイト常時SSL化のススメ - @IT

    2012/03/28 ログインや入力フォームなどが含まれないページも含め、Webサイト全体のSSL化を検討してほしい――日ベリサインは3月28日、常時SSL(Always-on SSL)に関する説明会を開催した。 米シマンテック シマンテックトラストサービシズ プロダクトマーケティング シニアディレクターのロブ・グリックマン氏は、「Webサイトのセキュリティはクリティカルな問題になっている」と述べ、主に2つの攻撃シナリオがあると説明した。 1つは、正規のWebサイトが攻撃者に乗っ取られて、アクセスしてきたユーザーにマルウェアを仕込んでしまうケース。もう1つは、通信経路で盗聴した情報によるなりすまし(セッションハイジャック)だ。 特に後者の問題に対する「簡単かつコスト効率に優れた解決策が、常時SSLだ」(グリックマン氏)という。すでに、FacebookやTwitterGoogle、Pay