4月 29th, 2009
Apache2.2からmod_proxy_ajpによって正? ぜ AJP13プロトコルがサポートされました。では、AJP13（Apache JServプロトコボ バージョボ 1.3）のメリットとは? なのでしょうか？
基本的ぜ AJP13は前バージョボ ajp12の? れを汲み、性能の向上を目木 としているようです。AJP13はパケット指向であることぜ HTTPと? ゜ らないのですが、プレーンテキスト形? ではなぜ バイナリ形? を採用して性能向上を狙っています。例えば、リクエスト/レスポンスヘッダ内のメソッドやヘッダは、”POST”や”accept-language”のような文字列ではなぜ 、1バイトのコードとして扱います。これによりパケット転送釜 の? 約になっています。
これ以? のメリット、というものはイマイチ見つけられませんでした・・ボ TomcatのコネクタにしてもHTTPぜ AJPで特にオプションの違いはないようです。直接バックエンドぜ Tomcatにアクセスされた時、HTTPのプロトコルを話せるよりも、AJPのプロトコルしか話せない方がセキュリティ的には好ましいという点は挙げられるかもしれません。
http://www.jajakarta.org/tomcat/tomcat-jk2/ja/docs/common/AJPv13.html
4月 8th, 2009
Sun朏 供ぜ JDKインストール? 、デフォルトでぜ Java暗号化拡張機? (JCE)に暗号化強度の制限がかかっています。暗号化強度とは、簡単に? えば暗号の解読され難さのレベルです。（ちなみに、暗号を平文に戻す作業は、正? の圏 信者が正? の手続きとして? う場合を複合化、本来暗号を読むべきでない第? 者が行う場合を解読という）この制限は、国際武器? 通? 制? で? 定強度以? の鍵の輸出に対して米政? が輸出制限をかけたものです。10年ほど前は、40～56bit以内でしたが、現在では地 しづつ緩んでいるようです。
この制限を解除するには、Sunのサイト（http://java.sun.com/products/archive/jce/）より暗号化制限解除版のポリシーファイルをダウンロードし、デフォルトのポリシーファイルと入れ替える必要があります。手順は以下のように単純です。
# ls -l ${JAVA_HOME}/jre/lib/security/*.jar
-r--r--r-- 1 root root 2469 9月 26 2008 ${JAVA_HOME}/jre/lib/security/US_export_policy.jar
-r--r--r-- 1 root root 2940 9月 26 2008 ${JAVA_HOME}/jre/lib/security/local_policy.jar
# unzip jce_policy-6.zip
# cd jce
# cp -pi US_export_policy.jar ${JAVA_HOME}/jre/lib/security/
# cp -pi local_policy.jar ${JAVA_HOME}/jre/lib/security/
# ls -l ${JAVA_HOME}/jre/lib/security/*.jar
-r--r--r-- 1 root root 2465 11月 17 2006 ${JAVA_HOME}/jre/lib/security/US_export_policy.jar
-r--r--r-- 1 root root 2481 11月 17 2006 ${JAVA_HOME}/jre/lib/security/local_policy.jar
# 制限版ポリシーファイボ
grant {
permission javax.crypto.CryptoPermission "DES", 64;
permission javax.crypto.CryptoPermission "DESede", *;
permission javax.crypto.CryptoPermission "RC2", 128,
"javax.crypto.spec.RC2ParameterSpec", 128;
permission javax.crypto.CryptoPermission "RC4", 128;
permission javax.crypto.CryptoPermission "RC5", 128,
"javax.crypto.spec.RC5ParameterSpec", *, 12, *;
permission javax.crypto.CryptoPermission "RSA", *;
permission javax.crypto.CryptoPermission *, 128;
};
# 解除版ポリシーファイボ
grant {
// There is no restriction to any algorithms.
permission javax.crypto.CryptoAllPermission;
};
一般的に暗号化強度128ビット以? であれば、セキュリティレベル的に問題ないと? ゜ れています。今のコンピュータではどの? の時間で解読されてしまうのか゜ かりませんが、56bitぜ DESが暗号解読コンテストで? 十時間で解読された、というレベル話ですので情報の? 密性にもよるかもしれません。暗号化強度が高いに? したことはありませんし、DES方? を使用する場合ぜ 64bitに制限されているようなので制限解除した方がいいかもしれません。
基本的にポリシーファイルを入れ替えるだけの更新であれば、稼働中のアプリケーションに? える影響は朮 どないと思゜ れます。ただし、JDK1.5からjavax.crypto.Cipherクラスが更新され、いぜ つかのメソッドが追加されています。もし、「最大暗号化強度の最大ビット数を圏 得後に最高強度で暗号化」のようなアプリケーションロジックが組まれていた場合には、影響があるかもしれません。
public static final int getMaxAllowedKeyLength(String transformation)
throws NoSuchAlgorithmException
public static final AlgorithmParameterSpec
getMaxAllowedParameterSpec(String transformation)
throws NoSuchAlgorithmException;
http://java.sun.com/javase/ja/6/docs/ja/api/javax/crypto/Cipher.html#getMaxAllowedKeyLength(java.lang.String)
