Webの表示速度を遅くする「SSLハンドシェイク」とは:現場にキく、Webシステムの問題解決ノウハウ(3) 本連載は、日立製作所が提供するアプリケーションサーバ「Cosminexus」の開発担当者へのインタビューを通じて、Webシステムにおける、さまざまな問題/トラブルの解決に効くノウハウや注意点を紹介していく。現在起きている問題の解決や、今後の開発のご参考に(編集部) 知っていますか? SSLハンドシェイク Webアプリケーションで提供するWebページにSSLを適用した場合、SSLでは通信相手の認証/通信内容の暗号化などの負荷の高い処理が実行されるため、WebページのWebブラウザに表示される速度が遅くなることがある。この現象は、SSLセッションを再利用して、「SSLハンドシェイク」(上記の認証/暗号化を含んだ一連の処理)を簡略化することで、解決できる場合がある。 今回は、それらの問題を
Windows XP、Vista、7の裏技や高速化をはじめ、問題解決方法、Autoitプログラミングについて紹介しています。自作ツールも配布しています。Windows XP、Vista、7の裏技や高速化をはじめ、問題解決方法、Autoitプログラミングについて紹介しています。自作ツールも配布しています。 最新の更新情報 2012/11/11 ・2012/11/03 の記事、Win7 解決!「Windows Media Player は正しくインストールされていないため、再インストールする必要があります。」に新しい方法を追記しました。 2012/11/03 ・メールおよびコメントでの質問再開は、現在多忙のため、もうしばらくお待ちください。 2012/08/18 ・多数の質問ありがとうございます。 現在質問件数がかなり多く、お返事に時間がかかるため、メールおよびコメントでの質問を一時休止致しま
@ymmt2005 こと山本泰宇です。 今回は cybozu.com を安全に利用するために暗号化した通信(SSL)を常時使用するための取り組みを紹介します。 HTTP と HTTPS HSTS とその弱点 Preloaded HSTS Chrome のリストに cybozu.com を組み込む まとめ HTTP と HTTPS Web ブラウザのアドレスバーに "www.cybozu.com" と打ち込むと、通常は暗号化されない HTTP 通信が行われます。そこでまず考えられるのは、Web サーバーにて HTTP 通信を受け付けたら、HTTPS に永続的リダイレクトをすることです。Apache なら以下のような設定になるでしょう。 <VirtualHost *:80> ServerName www.cybozu.com Redirect permanent / https://www.c
ユーザー名やパスワード等の機密情報をWebブラウザから入力する場合、盗聴される恐れがあるため、Webサーバー間の通信内容を暗号化する。 ここでは、Webサーバーにmod_sslを導入して、URLをhttp://~ではなく、https://~でアクセスすることによって、Webサーバー間の通信内容を暗号化するようにする。 なお、Webサーバーとの通信内容を暗号化するには、サーバー証明書を発行する必要があるが、ここでは、自作サーバー証明書を発行して各クライアントにインポートする。 ※サーバー証明書を各クライントへインポートしなくても暗号化通信は行えるが、クライアントが通信するたび(Webブラウザ起動毎)にセキュリティの警告が表示されてしまう [root@centos ~]# cd /etc/pki/tls/certs/ ← ディレクトリ移動 [root@centos certs]# sed -i
チカッパ!の共有SSLのアドレスがこの度、変更となりますが、運営側の説明では「セキュリティ対策」としております。 すごいですね「脆弱性を確認いたしましたのでセキュリティ対策します」と書いていますよ! 正直ですね。ステキです。大好き。 皆も正直なチカッパ!を使おう!! さて、今回の共有SSLのアドレス変更、何が問題だったのでしょうか? 普通に使っている分には、ちゃんと共有SSLが動作しているように見えたのですが… いえいえ、そんな事はありません。もしかしたら、あなたのサイトが誰かに乗っ取られていたかもしれないのです。 そんなまさか!? SSLだから安全じゃないの? 確かに。SSLはあなたの通信を暗号化してくれます。 ですが、SSLは暗号化をしてくれるだけであり、今回の問題とは無関係です。サーバ上で動作するプログラムの作りによっては重大なセキュリティホールに成り得たのです。 今日は古い共有
■ 共用SSLサーバの危険性が理解されていない さくらインターネットの公式FAQに次の記述があるのに気づいた。 [000735]共有SSLの利用を考えていますが、注意すべき事項はありますか?, さくらインターネット よくある質問(FAQ), 2010年2月10日更新(初出日不明) Cookieは、パスなどを指定することができるため、初期ドメイン以外では共有SSLを利用している場合にCookieのパスを正しく指定しないと、同じサーバの他ユーザに盗まれる可能性があります。 (略) 上記については、「同サーバを利用しているユーザだけがCookieをのぞき見ることができる」というごく限定的な影響を示していています。また、Cookieの取扱いについて、問い合わせフォームやショッピングカート等、ビジネス向けのウェブコンテンツを設置されていなければ特に大きな問題とはなりませんが、個人情報を取り扱われる管
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
「そんなの常識だよ」という人は無視してください。 知りませんでした。https://ページからhttp://ページへのリンクした場合リファラーは送出されないんですね。 昨日、弟から「https://ページからhttp://ページへのリンクした時にリファラーが取得できないのだけど、これって何が原因?」と聞かれ、「いや取れるだろ」と答えたのですがよくよく調べてみるとブラウザの仕様でhttps://ページからhttp://ページへのリンクした場合はリファラーは送出されないようです。 以下、産業技術総合研究所のページより引用 Internet Explorerのバージョン4.0以降を使用している場合には、Refererは送出されません。これは、Internet Explorerの4.0以降が、「https://」のページ上に存在するリンクを辿ったときにはRefererを送出しない仕様となっているた
phpMyAdmin に限らず、サーバ管理ツールやグループウェアなどの Web アプリケーションを利用する場合は、ツール側のセキュリティ対策は勿論ですが、Web サーバ側でも適切にセキュリティ対策(アクセス制限と監視) を行う必要があります。 phpMyAdmin の設置とは切り分けて考える必要があるため、ここでは例をあげて Apache Web サーバ側で適用するセキュリティ ポリシーについて考えます。 phpMyAdmin 設置ポリシー例 phpMyAdmin の設定は、config.inc.php を編集して行います。サーバ管理者が利用する phpMyAdmin と ローカルユーザに提供する phpMyAdmin それぞれに異なるセキュリティポリシーを適用したい場合は、異なるディレクトリで phpMyAdmin を設置します。 例えば、ドキュメントルート外にそれぞれの phpMyAd
SSLを考えずに作られているページを、.htaccessだけの変更でSSL対応する方法をご紹介します。 もちろん、サーバがSSLに対応している必要はありますが…。 さらに.htaccessとmod_rewriteが入っている必要もあります。 SSLページにしたいHTMLファイル(PHP等でも可)のあるディレクトリに.htaccessファイルを作成し、下の文を追加します。 RewriteEngine on RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L] ファイルを個別に指定したい場合はちょっと面倒ですが下記のようにします。 ここでは例としてfoo.htmlとbar.htmlをSSLページとし、それ以外はSSLでないページとします。 RewriteEngine on Rew
Webアプリケーションのぜい弱性がなかなかなくならない。メディアなどでも盛んに取り上げられているにもかかわらず,である。特に,セッション管理がからむアプリケーションのぜい弱性には,気付かないことが多い。具体的には「クロスサイト・リクエスト・フォージェリ」(CSRF),「セッション・フィクセーション」などである。これらはクロスサイト・スクリプティング,SQLインジェクションといった比較的メジャーなぜい弱性に比べて認知度が低く,対策も進んでいない。 原因の一つは,アプリケーションの開発者が原因を正しく理解していないこと。CSRFやセッション・フィクセーションについて言えば,セッション管理に使うクッキー(cookie)の動作を理解していないと対策が難しい。ところが最近の開発環境では,セッション管理の仕組みが隠ぺいされているため,必ずしもこの知識は要求されない。こうした開発者は容易にはぜい弱性に気
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く