Jboss4.2.3 SSL設定

以下の手順でJbossのSSL設定を行いました。

○キーストア生成
keytool -genkey -alias jbossl -keyalg RSA -keystore jboss.keystore -validity 3650

キーストアのファイル名「jboss.keystore」
エイリアス　　 　　　 「jbossl」
証明書有効期限         3650日
※JDK6ではカレントディレクトリに作成された

○クライアント証明の作成
keytool -export -alias jbossl -keystore clientKeys -file client.cer -keystore D:\jboss\server\default\conf\jboss.keystore

○キーストアへの証明書の登録
keytool -import -alias jbossl -file client.cer -noprompt -trustcacerts -keystore "C:\Program Files\Java\jdk1.6.0_10\jre\lib\security\cacerts"
※JDKのインストール先は各自適当に


○server.xmlの修正　

               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" keystorePass="jbossl" keystoreFile="D:/jboss/server/default/conf/jboss.keystore" />

SSL設定のコメントアウトをはずし有効にする。
keystorePass属性とkeystoreFile属性を追加。


うむ、とりあえずでけた。

参考URL
http://d.hatena.ne.jp/rainydaidoh/20060910/1157896090

TomcatとApacheの連携

環境
・Tomcat 6.0.10
・Apache 2.2.4


▼Apache httpd.confの設定
　・モジュールmod_proxy_ajpと、mod_proxyも設定を有効にする。
　　以下のコメントアウトを解除。

　　　LoadModule proxy_module modules/mod_proxy.so
　　　LoadModule proxy_ajp_module modules/mod_proxy_ajp.so

　・Locationの設定

　　<Location /docs/>
 　　 ProxyPass ajp://localhost:8009/docs/
　　</Location>

　※docsはTomcatのコンテキストルート


　※8009は、Tomcat側の連携コネクタポート番号

▼Tomcat server.xmlの設定
　・連携コネクタの設定を有効にする。
　　以下のコメントアウトを解除。


　

   <!-- Define an AJP 1.3 Connector on port 8009 -->
   <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
　※ ポート番号が8009になっていることを確認

CSS spriteに挑戦

ページのロードが遅いので画像リクエストを減らすことに。
CSSspriteってやつをやってみることにした。


使ったツールは「Tonttu」
http://collamo.jp/Tonttu/
AIR アプリなのでAdobe AIRをインストール。
http://www.adobe.com/jp/products/air/


最初にまとめる対象の画像を決める。
まず、repeat している背景画像には使えないので対象外に。
しかしrepeat している背景画像の多いこと多いこと。。
とりあえずグラデーションとかで置き換えられそうなとこは
画像を使わずCSSで対応。


次に、コンテンツとしての画像は対象外に。
alt属性が必要な画像は対象外としてユーザビリティの確保。


動的にサイズが変わる画像も対象外に。


まとめる対象の画像が決まったところで
「Tonttu」に放り込んで１枚の画像を生成。
CSSも一緒に生成されるので、それを元に
自分のCSSに適応させる。


微調整しつつなんとなく完成！


細かいとこまで確認していると、メニューの階層を表すアイコン画像が変なことに。
サイズが子要素に依存する要素の左端置いている画像なので、
子要素が２行になると一枚画像の１個下の画像が見えてる（汗
背景色も合ってない。。


ってことでまとめる画像間を広げてたり背景色を調整して
なんとか完成！！
以外に苦戦しました。


しかしメンテナンス性がかなり悪くなったな。
画像の変更やサイズ変更、CSS変更に手間がかかるようになってしまった。。


ちょっと気になったのは、「Tonttu」で１枚画像にする際、
縦に並べてたんだが、4000pxくらいを超えるとそれ以降の画像背景色が
何故か灰色になってしまう現象に遭遇。
まぁまとめる画像絞ったり、画像間の幅を短くしたり調整して
3000pxくらいに抑えたので問題なかったのだが、バグだろうか。。

jsessionidはURLリライトとCookieどっちが優先されるか

HttpServletRequest#getRequestSessionId()でURLに付加したjsessionidとCookieにセットしたjsessionidのどちらが取得されるのかという問題だが、sessionトラッキングのサーブレット仕様から考えてCookieが優先されるだろう（セキュリティ的にも）。


引用　Java Servlet 2.5 Maintenance Release 2 （抜粋）
==============================================

SRV.7.1.1 Cookies
Session tracking through HTTP cookies is the most used session tracking
mechanism and is required to be supported by all servlet containers.
The container sends a cookie to the client. The client will then return the
cookie on each subsequent request to the server, unambiguously associating the
request with a session. The name of the session tracking cookie must be
JSESSIONID.


SRV.7.1.3 URL Rewriting
URL rewriting is the lowest common denominator of session tracking. When a
client will not accept a cookie, URL rewriting may be used by the server as the basis
for session tracking. URL rewriting involves adding data, a session ID, to the URL
path that is interpreted by the container to associate the request with a session.
The session ID must be encoded as a path parameter in the URL string. The
name of the parameter must be jsessionid. Here is an example of a URL
containing encoded path information: ==============================================


でも一応試してみた。
javascriptのonloadで、actionURLにCookieに設定されているものとは異なるjsessionidを付加するコードを追加して、その画面のリクエスト時にサーバのHttpServletRequest#getRequestSessionId()でCookieとURLパラメータのどちらが取得されるか。


結果
 Tomcat6.0実装　Cookie
 Seaser2(2.4.25) 実装　Cookie
 Weblogic9.2実装　Cookie


まぁ予想通りの結果ですね。
ちなみにwebsphereは試していませんが、下記サイトにCookieが優先されると書いてあります。
http://www.cresc.co.jp/tech/java/Servlet_Tutorial/Lesson_53.htm

Tomcatを自己証明書でSSLにする方法

Tomcat6.0でWebアプリ開発をしていて、手軽にSSLを試せる方法です。


keystoreファイルを作成
  keytool -genkey -alias tomcat -keyalg RSA
  C:/Documents and Settings/ユーザ名/.keystoreに作成されたが、環境によって違うかも。

server.xmlのSSL設定のコメントアウトをはずす。

keystorePass、keystoreFile属性を追加。
・keystorePass属性にはkeystoreファイル作成時に指定したパスワード
・keystoreFile属性にはkeystoreファイルのパス
例）
   <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"   
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS"
               keystorePass="password" keystoreFile="C:/Program Files/Apache Software Foundation/Tomcat 6.0/conf/.keystore" />

Tomcatを再起動してSSLポート（8443)でアクセスでOK。


comodoとかで無償版SSLでちゃんとした証明書とることもできます。
http://jp.comodo.com/ssl-certificate-products/free-ssl-certificate.html


ApacheとTomcatを連携している場合はApacheでSSL設定を行います。
http://www.thinkit.co.jp/free/article/0706/3/7/

初回アクセス時のjsessionidを非表示にする

ブラウザを立ち上げて最初にアクセスしたときにjsessionidが付加されてしまう。


ソースを追ってみると、初回はHttpServletRequest#isRequestedSessionIdFromCookie() がfalseを返してHttpServlet#encodeURL()でjsessionidを付加してました。
原因は初回アクセスはcookieが有効かどうかわからないからですね。


Servlet仕様で、セッションIDの格納先にCookieが使用できないクライアントを想定してURLへセッションIDを文字列付加しての送信もサポートすることを推奨してるから、だいたいどのフレームワークも同じ実装だと思います（いわゆるURLリライティング）。とりあえず、StrutsとTeedaはそうでした。
回避方法は、最初にアクセスするページの前にダミーページを用意してリダイレクトを行うことでcookie有効判定に通せばよさそうですね。


ひがさんのブログに書いてありました。
http://d.hatena.ne.jp/higayasuo/20080724/1216889790


Teedaでは、ダミーのhtmlとPageクラスを用意して、PageクラスのprerenderでHttpServletResponse#sendRedirect()を呼び出すことでうまくいきました！


cookieが無効のクライアントをケアしないのであれば、Webサーバの設定等でにげれそうですね。
weblogicなら、weblogic.xmlのurl-rewriting-enabledをfalseに設定するとか、Apacheのmod_rewriteを使用するとか。
あとは、いけてないけど判定ロジックを部分を拡張するとかもありますね。
TeedaだとServletExternalContextImpl #encodeActionURL()を拡張すればよさそう。


ちなみにSSLにすれば、HTTPのボディだけじゃなくてヘッダも暗号化されるんだよね？
という疑問が沸いたので調べてみた。
じゃないとリファラとかでURLパラメータの方が危険性は高いと言っても、
ネットワークには平分で流れちゃうし。


SSLはTCP階層の暗号化なので、HTTPのヘッダもボディも暗号化されるようです。
GETパラメータももちろん暗号化されますね。
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=1991&forum=12





















SSLとjavascript（IEの警告ダイアログ対応）

作成してるWebサイトをSSLにしたとたん、以下のようなメッセージの警告ダイアログがやたら表示されたので、原因と対処方法まとめ。

「このページにはセキュリティで保護されている項目と保護されていない項目が含まれています。保護されていない項目を表示しますか?」

基本的には、httpのリクエストとhttpsのリクエストが混ざっているページで表示されるダイアログのはずなので、パケットモニタしてリクエストを見てみたが、「http:」で始まるリクエストは飛んでない。

ググってみると、どうもiframeのsrc属性が空の場合にも発生するようだ。 http://support.microsoft.com/kb/261188/ja

なんてこった、画面部品としていくつかsrc属性なしでiframeを使用しているわ。

IE6、7、8で試したが出るのはIE６のみ。
基本的にはインターネットオプションの「保護つき/保護なしサイト間を移動する場合に警告する」のチェックをはずせば問題ないのだけど、IE6のデフォルトはチェックあり。。

対応方法は、ダミーのhtml（空ファイル）を用意して、src属性に指定するだけです。
.htmlに対してservletが動作してしまう設定のときはdummy.htmとか適当に拡張子を変更すればOK.

よし、解決！ と思っていたら今度は別Windowを使ってところで
以下の警告ダイアログが。。

「セキュリティで保護されたページに接続します」

「セキュリティーで保護されていないページに移動しようとしています」

window.openのURLパラメータを指定していないとこが原因の模様。

window.openでURLパラメータに空を指定していると、SSL切断→SSL接続という

動きになりSSL開始と終了の警告ダイアログが表示されるみたい。

これも対応方法は、iframeと同様でダミーHTMLを指定することで解決。

2010/07/17追記

ちなみにiframeの方はsrc="javascript:false"みたいな書き方でもいけるが、
透明でレイヤーにしてるiframeとかの場合、falseって文字が出ちゃいますw
文字が出ちゃうとか関係ない用途なら こっちの方が リクエスト発生しない
のでパフォーマンス的によいね。

window.openの方はjavascript:falseは効果ありませんでした。