セキュリティ・キャンプ全国大会2016 集中講義
ご無沙汰しております。細羽です。 昨年、AndroidにおけるSNI対応状況という記事で、SSL/TLSの拡張仕様であるSNI(Server Name Indication)について触れました。 少しニッチなテーマだと思っていましたが、つい先日、さくらのレンタルサーバでSNI SSLを提供開始というプレスリリースが発表されました。広いサービスでSSL/TLS導入への需要が高まっている今、このような事例は今後増えていくものと考えられます。 そこで本記事では、重要度が高まっているSNIについて、その技術の概要を改めて理解し、実際の運用に役立てられるように整理をしたいと思います。 知識の整理を目的にした前編と、実践を目的にした後編の2部構成でお届けします。 以下が前編の内容です。 SNIで何が出来るようになるのか SNIで複数ドメインが運用可能になるまで SNIが重要になりつつある背景 SSL運
はじめまして。株式会社ガラパゴスの細羽と申します。このたび、さくらのナレッジに寄稿させていただく事になりました。よろしくお願いいたします。 弊社は、スマートフォンアプリの受託開発を主な事業としており、アプリ単体の新規開発のみならず、以下のようなトータルなサービス提供を強みにしております。 モバイル戦略の立案:ビジネスモデル分析・KPI・KGI策定・運用設計など サービス全体の開発:サーバサイドまで含めたサービス全体の設計・開発 既存サービスのモバイル対応:お客様の既存資産(WEBサービスやDB)を活用してモバイル対応させるための開発プラン提案・実行 このような領域で開発業務に取り組んでいると、新規サービスの開発ではあまり直面しない、一風変わった技術的な課題に直面することも少なくありません。この中でも特に、サーバやインフラに関するナレッジを今後共有していけたらと思います。 テーマ 本日のテー
Editor's Note: SSL Is Now Included on All Paid Dynos as of September 22, 2016 At Heroku, we want to make it easy for everyone to be able to learn and explore our service, and the related ecosystem of technologies, for free - be it student, professional developer, hobbyist or just curious individual. We view this as both part of our mission and our business model; it has never been a more interesti
既に12月22日ですが、このエントリーは、Node.js Advent Calendar 2014の13日目のエントリーです。 いや私が書くの遅れたわけじゃないですけど…(言い訳)、ちょうどタイムリーなネタがあるので、先日リリースされたNode-v0.10.34で発生した(現在も継続している)問題について携わった経緯を自分の目線で書いてみます。 追記:日本時間の12/24にNode-v0.10.35がリリースされました。 http://blog.nodejs.org/2014/12/23/node-v0-10-35-stable/ 本記事の不具合も修正されています。 1. Node-v0.10.34リリース直後にissue発生 先週12/17にNode v0.10.34 (Stable)がリリースされました。10月中旬にPOODLE騒ぎでOpenSSLに対応した Node-v0.10.33
I released Furl 2.00. It contains very important and incompatible change. Furl now verify every SSL certifications by default. If your application communicates server, is using unverified SSL certs, this version breaks your application. If you want to back older behavior, you need to specify `ssl_opts` option. -Furl が 2.00 でデフォルトで SSL 証明書をきびしくチェックするようになりました。そしてこの挙動がデフォルトとなりました。オレオレ証明書をつかっている場合には通信
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを1往復させないといけないのである。パケットの往復
FreeBSD の Dropbox-api コマンドが突然メッセージを吐き出すようになってしまった。 ******************************************************************* Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client is depreciated! Please set SSL_verify_mode to SSL_VERIFY_PEER together with SSL_ca_file|SSL_ca_path for verification. If you really don’t want to verify the certificate and keep the connection open to Man-In-The-Mi
LWP::UserAgent の HTTPS 対応は LWP::Protocol::https というパッケージに分離されました 最近あたらしい Perl の環境を作って LWP を入れて https なページにアクセスしようとしたら LWP will support https URLs if the LWP::Protocol::https module is installed.って言われてビビるかもしれません。 それは https 対応するモジュールが別ですと李に分離されたためです。 そういう時は迷わずLWP::Protocol::httpsを入れればいいです。 Posted by Yappo at 2011年04月26日 19:24 | TrackBack | Perl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く