Javaアプレットの署名とJavaセキュリティのいくつかの微妙な点

問題文：

WYSIWYG XMLエディターとして、アプリケーションはJavaアプレットOxygen Author Componentを使用します 。 このアプレットをクライアントにロードするとき、Javaは安全でないコードに関する恐ろしい警告を投げ出してはいけませんが、ユーザーに負担をかけず、重い責任を負わずに静かに静かにアプレットをロードします。 結局のところ、しっかりしたアプリケーションがあります。

プロローグ

この記事は科学的に検証され、正確であるふりをするものではありません;定義の不正確さを認めます。 私はウィキペディアを開かなかった、私は書いている、いわば、心からですが、コメントは受け入れられます。

アプレットが指でどのように機能するか

HTMLページでタグが検出されると、ブラウザはアプレットのロードの制御を対応するJavaプラグインに転送し、JavaプラグインはクライアントマシンにインストールされたJREに制御を転送します。 アプレットをダウンロードするには2つの方法があります（アプレットとは、特定のJavaアプリケーションを意味します。これは、jar-okのセットであり、アプレットクラスを実装するMainクラスを持つメインjarがあります）。

• Appletタグでは、ダウンロードする必要があるアプレットのjarファイルとそれらのロード元が転送されます（コードベース）
• この情報が示されているjnlpファイル、および他の多くのオプションと引数を使用する

この例では、jnlpを使用します。 jnlpアプローチの利点は、とりわけ、アプレット（たとえばコードベース）をロードするためのパラメータを変更するときに、アプレットのロードを担当するHTMLまたはJavaScriptコードを変更する必要がないことです。 jnlpを変更するだけです。 絶対URLを指定する必要があるため、コードベース（コードベースはjarアプレットの場所を示すURLアドレスです）を置き換えることは、アプレットが実行されているサーバーに応じてコードベースである必要があることを意味するため、かなり不快な問題です。 ローカルマシンでは、これは1つのアドレスであり、QAでは別のアドレスであり、本番では3番目のアドレスです。そのため、アプリケーションを構築するときは、コンテキストパス、つまり動作するWebアプリケーションの絶対アドレスを明示的に指定する必要があります

jnlpファイルを使用すると、クライアントがjnlpファイルをロードするときに動的にコードベースを動的に変更する特別なサーブレットが存在するという事実により、この問題を解決できます。

行こう

そのため、アプレットの読み込みは、必要なjarファイルとそのコードベースのリストに加えて、クライアントマシンでこのjavaを起動するjava引数（これは非常に重要なポイントです。以下で理由を確認します）も含むjnlpファイルの読み込みから始まります。 Javaはjarのロードを開始し、セキュリティをチェックします。 これは、クラスがロードされる前にダウンロード可能なフライをチェックし始めるJavaセキュリティメカニズムの出番です。 このメカニズムはかなり複雑で多面的です。アプレットとJavaセキュリティポリシーをクライアントに読み込む際の一般的なセキュリティレベルの設定（許可付与）、jar自体のマニフェストのセキュリティパラメータ、検証、jarのデジタル署名の検証など。 深く掘り下げたくはないので、説明した問題で重要な側面のみに触れます。



参考：アプレットに署名することは、jarファイルに署名することを意味します。 jarに署名すると、javaコマンドsignjarが実行され、その結果、暗号化された形式で署名されたキーに関する情報がjarに表示されます。また、各リソースパックjarには、このコンテンツに関する情報を含むこのキーで暗号化されたコードが割り当てられますリソース。 したがって、署名されたフライを変更しようとすると（たとえば、そこにクラスをスローしたり、古いクラスを変更したりすると）、そのようなフライは無効になり、セキュリティチェックに合格せず、ロードされません。





そのため、アプレットは署名、自己署名、または信頼できる証明書によって署名されない場合があります。 アプレットがロードされるクライアントJavaのバージョンに応じて、アプレットのサブスクリプションレベルは、アプレットがロードまたはブロックされるかどうかに影響しますが、「このアプレットを実行することに同意すると、グローバルな大変動が発生し、一般的にすべてが消えます」などの警告とメッセージが多数表示されます自己責任で実行してください ''







または、適切なチェックマークをクリックしても、今後繰り返すことのできない美しく威圧的なメッセージを1つダウンロードします。 ここで、実際にタスクに到達しました。 上記の問題を解決する時点で、酸素アプレットは自己署名されました。 つまり、署名は偽物でしたが、偽物です-キーはkeytoolユーティリティの助けを借りて生成されました。

当然のことながら、そのようなアプレットをロードするとき、javaは糞をファンに投げつけて呪いをかけましたが、長い目で見ればアプレットをロードしました。 しかし、これらのメッセージを取り除く必要があったため、信頼できる証明機関（Trusted Certifictae Authority）からの証明書が必要でした。



そのため、信頼できるセンターからの証明書が必要です。 入手方法 簡単だが楽しいことは安くない。 1年間の証明書の費用は約500アメリカ人です。 センターwww.verisign.comのサービスを使用しました。 エイリアスとパブリッシャーに関するその他の情報を使用して（keytoolユーティリティを使用して）キーストアを作成し、特別なリクエストを作成する必要があります（そしてもちろん支払います）。 応答として、CAはキーを送信します。 私たちが送信したのは、コード署名証明書、中間CA証明書、pkcs7形式の証明書の3つです。 JKS証明書タイプの場合、中間証明書とコード署名証明書が必要です。 最初に、以前に作成されたキーストアに中間証明書が追加され、次にメインのコード署名証明書が追加されます。 結果のキーストアは、jarの署名に使用されます。



あなたのフライが以前に署名されていた場合（そして、私の場合、署名された、または自己署名されたもの）、再度署名する前に、最初に古い署名を削除する必要があります。 そうしないと、アプレットをダウンロードするときに、Javaが最初のフライを止めて地獄に送られます。 たとえば、META-INFフォルダーから.RSA（または.DSA）および.SFファイルを手動で削除したり、マニフェストファイルからすべてのダイジェストリソース署名を削除したりして、署名を削除できます。

私はほとんど忘れていました。jarに署名する前に、セキュリティ属性をマニフェストに追加する必要があります。

Permissions: all-permissions Codebase: * Caller-Allowable-Codebase: * Application-Library-Allowable-Codebase: *
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

更新51以降、セキュリティ属性を含まないすべてのjarは自動的にブロックされます。

そして、これはこのためのantスクリプトです：

  <target name="addSecurityProperty"> <jar file="${jarFile}" update="true"> <manifest> <attribute name="Permissions" value="all-permissions"/> <attribute name="Codebase" value="*"/> <attribute name="Application-Library-Allowable-Codebase" value="*"/> <attribute name="Caller-Allowable-Codebase" value="*"/> </manifest> </jar> </target> <target name="addSecurityProperties" if="hasForEach"> <foreach target="addSecurityProperty" param="jarFile"> <path> <fileset dir="lib" includes="**/*.jar, **/*.zip"/> </path> </foreach> </target>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

重要：このスクリプトでforeachを使用するには、antcontribが必要です。



したがって、フライをきれいにし、必要な属性をマニフェストに追加し、署名し、起動します...再び警告が表示されます！







また？ 稚魚だけでなく、jnlpファイルにも署名する必要があることがわかりました。 署名する方法は？ など 。 読みにくい：jnlpファイルはJNLP-INFディレクトリのメインjarにスローされ、ファイル名はAPPLICATION.JNLPのようになります。 質問ではありません。メインjarを作成してjarに署名するantスクリプトに追加します。ソースjnlpを署名付きjnlpにコピーする簡単なコードです。

  <target name="compile"> <mkdir dir="classes"/> <javac srcdir="src" destdir="classes" includeantruntime="false" debug="on"> <classpath> <fileset dir="lib"> <include name="*.jar"/> </fileset> </classpath> </javac> <mkdir dir="classes/JNLP-INF"/> <copy file="author-component-dita.jnlp" tofile="classes/JNLP-INF/APPLICATION.JNLP" overwrite="true"/> </target>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

父親はすぐにそれを理解しますが、万が一に備えて、この反ターゲットで何が起こるかを説明します。 最初の部分では、すべてが明確です-クラスディレクトリを作成し、そこでアプレットコードをコンパイルします。 コンパイル中に、libフォルダーがクラスパスに追加されます。これには、jar-okの束があり、アプレットが必要であり、それらすべてに署名する必要があります。 次に、JNLP-INFフォルダーがそこに作成され、元のフォルダーがそこにコピーされます。

author-component-dita.jnlp。

次に、すべてをjar（これがメインjar）にパックし、残りのjarの隣の同じlibフォルダーにドロップします。

現在、2つのjnlpファイルがあります。元のauthor-component-dita.jnlpとAPPLICATION.JNLPはjarにパッケージ化されています。 ちょっと気になります アプレットを起動します-エラー！







今回は何？ これらのjnlpファイルは一致しませんが、一致することがわかります。 元のjnlpはアプレットのダウンロードに使用され、パッケージ化されたものは署名の検証に使用され、それらは異なってはなりません。 しかし、なぜ彼らは異なるのですか、彼らはコピーですか？ そしてここで、Webアプリケーションのデプロイメントを容易にするために使用される素晴らしいサーブレット（ JnlpDownloadServlet ）を思い出します。これについては、前述しました。 これを使用すると、jnlpに特定のコードベース（たとえば、localhost：8888 / oxygen-editor /）を書くことはできませんが、 $$CODEBASE



変数を使用すると、ランタイム自体のサーブレットは必要な変数値をjnlpに代入して変更します。 これが、ダウンロード可能なjnlpが署名されたものと一致しない理由です。 どうする？ サーバーアドレスごとに異なる醸造物を展開しますか？ これは私たちのやり方ではありません。 簡単です：APPLICATION.JNLPの代わりにAPPLICATION-TEMPLATE.JNLPを使用する必要があります。 APPLICATION-TEMPLATE.JNLPテンプレートの使用は、特定のパラメーター値の代わりに「*」を指定した場合、たとえばcodebase = "*"の場合、元のjnlpと異なる可能性があるという点で異なります。 Antov build.xmlを変更しましょう：

 <target name="compile"> <mkdir dir="classes"/> <javac srcdir="src" destdir="classes" includeantruntime="false" debug="on"> <classpath> <fileset dir="lib"> <include name="*.jar"/> </fileset> </classpath> </javac> <mkdir dir="classes/JNLP-INF"/> <copy file="author-component-dita.jnlp" tofile="classes/JNLP-INF/APPLICATION-TEMPLATE.JNLP" overwrite="true"/> <replace file="classes/JNLP-INF/APPLICATION-TEMPLATE.JNLP" token="@@CODEBASE@@" value="*"/> <replace file="classes/JNLP-INF/APPLICATION-TEMPLATE.JNLP" token="@@HREF@@" value="*"/> </target>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

だから、本当にすべてであり、アプレットをロードするときに、アプレットが信頼され、信頼でき、疑わないという青いシールド付きの待望のユーザーフレンドリーなメッセージが最終的に表示されますか？ 私の幸せを信じずに、震える手で、アプリケーションを起動し、アプレットをダウンロードして...







やった！ 起こった！ 私はついに青い盾でこのメッセージを見ました！ そして、喜びのよだれを吹きかけ、「常にこの発行元を信頼する」チェックボックスをクリックして閉じ、アプレットがロードを開始し、...が表示されます。







なんて...！？ すぐに白髪になり、私は必死にコードにそれを貼り付け始めます-そんなに非セキュリティなのは何ですか？ 一般に、jnlpファイルで次の行を見つけるためにさらに2日間殺しました。

 <j2se java-vm-args="-Xmx512m -XX:MaxPermSize=80m -Xss4m -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5021" version="1.6+" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらは、アプレットの起動に使用されるjava引数です。 したがって、 デバッグ引数はnon-securityです。 アプレットが署名され、信頼できる証明書を使用している場合、これらの引数は禁止されています。 興味深いことに、アプレットが自己署名されている場合、実行可能なアプリケーションが不明であるとクライアントに警告されるため、最初は危険であるため、ダッシュを少しでも実行してアプレットを実行します。



禁止されている引数の完全なリストは次のとおりです。

 // note: this list MUST correspond to native secure.c file private static String[] secureVmArgs = { "-d32", /* use 32-bit data model if available */ "-client", /* to select the "client" VM */ "-server", /* to select the "server" VM */ "-verbose", /* enable verbose output */ "-version", /* print product version and exit */ "-showversion", /* print product version and continue */ "-help", /* print this help message */ "-X", /* print help on non-standard options */ "-ea", /* enable assertions */ "-enableassertions", /* enable assertions */ "-da", /* disable assertions */ "-disableassertions", /* disable assertions */ "-esa", /* enable system assertions */ "-enablesystemassertions", /* enable system assertions */ "-dsa", /* disable system assertione */ "-disablesystemassertions", /* disable system assertione */ "-Xmixed", /* mixed mode execution (default) */ "-Xint", /* interpreted mode execution only */ "-Xnoclassgc", /* disable class garbage collection */ "-Xincgc", /* enable incremental gc. */ "-Xbatch", /* disable background compilation */ "-Xprof", /* output cpu profiling data */ "-Xdebug", /* enable remote debugging */ "-Xfuture", /* enable strictest checks */ "-Xrs", /* reduce use of OS signals */ "-XX:+ForceTimeHighResolution", /* use high resolution timer */ "-XX:-ForceTimeHighResolution", /* use low resolution (default) */ "-XX:+PrintGCDetails", /* Gives some details about the GCs */ "-XX:+PrintGCTimeStamps", /* Prints GCs times happen to the start of the application */ "-XX:+PrintHeapAtGC", /* Prints detailed GC info including heap occupancy */ "-XX:PrintCMSStatistics", /* If > 0, Print statistics about the concurrent collections */ "-XX:+PrintTenuringDistribution", /* Gives the aging distribution of the allocated objects */ "-XX:+TraceClassUnloading", /* Display classes as they are unloaded */ "-XX:SurvivorRatio", /* Sets the ratio of the survivor spaces */ "-XX:MaxTenuringThreshol", /* Determines how much the objects may age */ "-XX:CMSMarkStackSize", "-XX:CMSMarkStackSizeMax", "-XX:+CMSClassUnloadingEnabled",/* It needs to be combined with -XX:+CMSPermGenSweepingEnabled */ "-XX:+CMSIncrementalMode", /* Enables the incremental mode */ "-XX:CMSIncrementalDutyCycleMin", /* The percentage which is the lower bound on the duty cycle */ "-XX:+CMSIncrementalPacing", /* Automatic adjustment of the incremental mode duty cycle */ "-XX:CMSInitiatingOccupancyFraction", /* Sets the threshold percentage of the used heap */ "-XX:+UseConcMarkSweepGC", /* Turns on concurrent garbage collection */ "-XX:-ParallelRefProcEnabled", "-XX:ParallelGCThreads", /* Sets the number of parallel GC threads */ "-XX:ParallelCMSThreads", "-XX:+DisableExplicitGC", /* Disable calls to System.gc() */ "-XX:+UseCompressedOops", /* Enables compressed references in 64-bit JVMs */ "-XX:+UseG1GC", "-XX:GCPauseIntervalMillis", "-XX:MaxGCPauseMillis" /* A hint to the virtual machine to pause times */ };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご清聴ありがとうございました。この記事がお役に立てば幸いです。