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/TLSのセキュリティ問題が多発しているため、自分で運用しているサーバのSSL/TLSの設定をテストしたいという人は多いと思います。 SSL/TLSの状態をチェックするには、Qualys SSL LabsのSSL Server Testがよく使われます。しかしこれは外部から第三者にスキャンさせるわけですから、(心理的・社内政治的な)敷居が高いという点もありますし、そもそもインターネット側から直接接続できない環境のテストが行えません。 そこで、IPアドレスを指定するだけでよろしく対象のSSL/TLSサーバの状態をチェックしてくれるツールがあると便利だな、ということになります。本稿では、このような目的に利用されるsslscanというコマンドを紹介します。 sslscanはLinuxで動作し、ペネトレーションテスト用に使われるKali Linuxにもインストールされているお手軽なSS
Last Updated: 11/10/2017 At Commando.io we make sure we are always on top of any potential security exploits or vulnerabilities. Unfortunately, lately there has been a steady stream of SSL related issues (Heartbleed and POODLE come to mind). Fortunately patching some of the most prominent issues only requires updating a few NGINX directives. We figured we would share our SSL NGINX configuration bl
----------------------------------------------------------------------------- 2015/03/03 9:00 PM PST - 更新 以下にリストされている AWS のサービスは、この問題を調査および対処している最中です。他のすべての AWS のサービスは影響を受けません。 Amazon Elastic Load Balancing (ELB) エクスポート暗号スイート (「EXP-」で始まるもの) を使用していることが判明したお客様には、注意喚起のために E メールで直接連絡します。推奨される利用可能な暗号セットを確実に使用するために、ロードバランサーで事前定義されたセキュリティポリシーを使用することをお勧めします。次の手順に従って、AWS コンソール経由で事前定義されたセキュリティポリシーを有効にできます。
In this session I will present best practices of how open source tools (used in the DevOps and security communities) can be properly chained together to form a framework that can - as part of an agile software development CI chain - perform automated checking of certain security aspects. This does not remove the requirement for manual pentests, but tries to automate early security feedback to deve
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、システム統括本部 プラットフォーム開発本部 セキュリティテクノロジー部 セキュリティスペシャリストの戸田 薫です。 今回は、SSLサーバ証明書に関してお伝えします。 SHA-1からSHA-2へ 「SHA-1」の危殆化を背景にSHA-1証明書の利用禁止に関する工程表が業界団体や企業から告知されています。 CAブラウザフォーラム(ブラウザベンダーの業界団体) 2017/01/01以降、SHA-1証明書を利用したSSLサイトとのSSL通信と禁止する。 Google Chrome 2015年上旬(詳細時期未定)以降、「有効期限が2016/01/01以降」のSHA-1証明書を利用したSSLサイトにアクセスした場合、警告メッセージ
Websites could use a security feature of your iPad to track your browsing even if you clear the browser history or completely replace the device. Demonstration ... This is a unique value that was generated by JavaScript in this page. The page attempts to store this value in your web browser and read it again when you visit the page in the future. Different web browsers don't behave exactly the sam
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
はじめに SSLv3のパディングに注目した攻撃手法であるPOODLEは、以前こちらのブログのエントリで取り上げたことがあるBEASTとCRIMEに非常によく似た攻撃です。今回はこのPOODLEについて、一般的な視点とはやや異なる、筆者独自の意見を述べてみたいと思います。 必ずしもSSLv3を無効にする必要はない POODLEの対策として書かれている情報はそのほぼ全てが「SSLv3を無効にする」というものですが、個人的には技術的にもう少し踏み込んで考えてみても良いのではないかと感じます。私は以前のエントリで次のように指摘しています。 BEASTもCRIMEも、意図しないリクエストが飛ばされ、そこにCookieが自動的に含まれてしまう点を攻撃するという意味で、CSRF攻撃の一種だと言えるでしょう。BEASTが発表されたらBEAST対策(RC4にする/TLSをバージョンアップする)を行い、CRI
HTTPS(SSL利用)サイトがSEO的に優遇されるトレンドで、世間的にもHTTPS接続でサイト運用するサービスが増えてきています。 これが、ハイトラフィックサイトになってくると、このフロントエンドでSSL処理させることが負荷的にもなかなか辛いのです。 で、Apache 2.3以降では、Shared Object Cache Providerとして、memcachedが選択できるようになっています。 この仕組みを利用して、Apacheとmemcachedを並べることで、各サーバでユーザのSSL Session Cacheを共有しながらHTTPSリクエストを負荷分散できる構成を作ってみました。 WebサーバでSSLオフロード 常時SSLを利用したWebサイトを運用するために、SSLアクセラレータといったアプライアンス製品だとか、ソフトウェアだとApacheやNginxのSSLモジュールを使う
Here at SpazioDati we build a lot of JVM applications (Java and Scala), and we often need a HTTP client. When the application is part of a batch process, and performance or stability are not the main concerns, we have been satisfied by jetty-client and Ning’s asynch-http-client. However, we have to admit that Apache HttpComponents is the most stable, mature and fully-featured HTTP client for Java
WebPayは現在、Apple Payへの対応を進めています。 Apple PayではElliptic Curve Cryptographer(ECC、楕円曲線暗号)が用いられるという事前の情報に基づき、Elliptic Curve Integrated Encryption Scheme (ECIES)の実装を行いました。 結局、Apple Payで送信される暗号文はECIESの形式を満たすものではなかったため、そのまま利用することはできませんでしたが、 この実験を通じて得た知見をもとにテンポよく実装を進めることができました。 本記事はその知見を共有することを目指して、ECIESについて簡単に説明したあと、 実験的に実装したRubyライブラリ、openssl-pkey-ec-iesを紹介します。 ECIESとは Elliptic Curve Integrated Encryption S
セクティゴジャパン(旧コモドジャパン)からのお知らせ 全てのSSLサーバ証明書がセキュリティ強度の高い楕円曲線暗号とSHA2に対応 お客様各位 平素はコモド製品をご利用くださいまして、誠にありがとうございます。 この度、弊社が販売するすべてのSSLサーバ証明書が、次世代の暗号アルゴリズムである 楕円曲線暗号およびSHA2に対応。よりセキュリティ強度の高いSSLサーバ証明書が 販売可能となりました。 楕円曲線暗号(ECC)は、楕円DSA(ECDSA)方式を採用することで、 高いセキュリティ強度を実現しました。 また、従来のRSAに比べ暗号鍵長が短いため、 SSL暗号化通信を処理するハードウェアの負荷を低減することが可能です。 ・ecdsa-with-SHA224 (RFC5758) ・ecdsa-with-SHA256 (RFC5758) ・ecdsa-with-SHA384 (RFC575
A month ago, I published an article on the compared performance of stunnel, nginx and stud as TLS terminators. The conclusion was to use stud on a 64-bit system, with session caching and AES. stunnel was unable to scale properly and nginx exhibited important latency issues. I got constructive comments on many aspects. Therefore, here is the second round. The protagonists are the same but both the
この頃、SSLの暗号化などにストリーム暗号RC4を使わないほうがいいといった話がよく聞かれるようになった。 2013年版のCRYPTREC暗号リストでも128bitのRC4が「運用監視暗号リスト」に入っているし、先日には、Microsoftからストリーム暗号RC4を使わないようにというセキュリティアドバイザリが出ている。 CVEとしては今年の3月に出ているようだ。 NVD: Vulnerability Summary for CVE-2013-2566 JVNDB-2013-001910 そこで、ここでは実際にPythonでRC4を実装し、RC4の脆弱性に関する簡単な例を再現してみる。 ストリーム暗号とは何か 暗号には大きく分けて公開鍵暗号と共通鍵暗号がある。 公開鍵暗号は、他人に見られても大丈夫な鍵(公開鍵)と自分だけが知っている鍵(秘密鍵)のペアを使って暗号化するもので、代表的なものに
■ 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと 「コンピュータセキュリティを基礎から」というと、暗号の解説、特に共通鍵暗号と公開鍵暗号の違いからなどといった解説をよく目にする。昔は専門の方によって注意深く書かれていたのに対し、ここ何年かはひどい状況になっている。先月、宮崎で開かれたSCIS 2008の席でも暗号研究者の方々との雑談でそういう話になった。私は暗号は専門でないのでその話題は迂闊に書けないできたが、このところの巷の誤り解説の氾濫ぶりは目に余るものがある。 最もひどく蔓延っていてしばらく消えそうにない間違い解説の典型例は次だ。 「公開鍵で暗号化したものを秘密鍵で復号するのと同様に、秘密鍵で暗号化したものを公開鍵で復号できるようになっている。」 事例1: 日本ベリサイン株式会社による公開鍵暗号方式の解説 このような共通鍵暗号方式の問題点を解決する暗号方式が、公開鍵暗号方式
© 2011 NTT Information Sharing Platform Laboratories SSLにおける暗号危殆化サンプル調査の報告 PKI day 2011 (2011.9.26) NTT情報流通プラットフォーム研究所 セキュリティマネジメント推進プロジェクト 武藤 健一郎 Copyright(c)2011 NTT CORPORATION. All Rights Reserved. 2 © 2011 NTT Information Sharing Platform Laboratories 本日の話題 • 背景 – 暗号危殆化 – 暗号危殆化に関する動向 – 暗号技術を利用した実サービスの例 – SSLで利用する暗号 • SSLサンプル調査の概要 – 調査概要 – 調査内容 • 調査方法・調査結果・考察 – 調査1:証明書における利用暗号 – 調査2:サーバの暗号設定(接
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く