Nous avons résumé les actions à entreprendre lorsqu'une erreur (IO Exception: Connection reset) se produit lors de l'exécution d'un outil appelé OWASP dependency-check.
En gros, c'est une erreur qui s'est produite car le JDK utilisé dans l'environnement ne pouvait pas prendre en charge la suite de chiffrement spécifiée par le site à partir duquel les informations de vulnérabilité ont été acquises. La solution était d'ajouter une bibliothèque appelée Bouncy Castle au JDK de l'environnement qui fournit une API pour le chiffrement.
A l'origine, je travaillais sur la coopération entre Vuls et OWASP dependency-check. https://vuls.io/docs/ja/usage-scan-non-os-packages.html#usage-integrate-with-owasp-dependency-check-to-automatic-update-when-the-libraries-are-updated-experimental
ERROR - IO Exception: Connection reset
2018-03-08 10:28:05,137 org.owasp.dependencycheck.utils.Downloader:280
DEBUG - Exception details
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:197)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:944)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1342)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1369)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1353)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
at org.owasp.dependencycheck.utils.Downloader.getLastModified(Downloader.java:268)
at org.owasp.dependencycheck.utils.Downloader.getLastModified(Downloader.java:235)
at org.owasp.dependencycheck.data.update.NvdCveUpdater$TimestampRetriever.call(NvdCveUpdater.java:507)
at org.owasp.dependencycheck.data.update.NvdCveUpdater$TimestampRetriever.call(NvdCveUpdater.java:480)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622)
at java.lang.Thread.run(Thread.java:748)
Il y avait un problème dans la même situation. https://github.com/jeremylong/DependencyCheck/issues/561
C'est long, mais après tout https://github.com/jeremylong/DependencyCheck/issues/561#issuecomment-257045439 C'était qu'il n'y avait pas assez de Bouncy Castle.
Il y a aussi un commentaire indiquant que tout va bien car le dernier Open JDK est inclus. https://github.com/jeremylong/DependencyCheck/issues/561#issuecomment-267774165
https://stackoverflow.com/questions/40305004/java-tls-connection-reset-using-some-jdks
La réinitialisation de la connexion a été définie car le JDK ne pouvait pas prendre en charge la suite de chiffrement de communication TLS utilisée par nvd.nist.gov, qui fournissait les informations de vulnérabilité.
Ce n'est pas grave si le JDK peut prendre en charge la suite de chiffrement correspondante.
manière https://stackoverflow.com/questions/31971499/ecdhe-cipher-suites-not-supported-on-openjdk-8-installed-on-ec2-linux-machine
Procédure japonaise https://www.intra-mart.jp/document/library/sso/public/im_sso_setup_guide/texts/install/login_server_config/security_provider/index.html
$ type java
java is /usr/bin/java
$ ls -lha /usr/bin/java
lrwxrwxrwx 1 root root 22 13 août 2017/usr/bin/java -> /etc/alternatives/java*
$ ls -lha /etc/alternatives/java
lrwxrwxrwx 1 root root 46 13 août 2017/etc/alternatives/java -> /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java*
$ cd /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/lib/ext # <-Bcprov ici-jdkXX-YYY.Placer le pot
$ vim /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/lib/security/java.security # <- java.Emplacement de sécurité
$ cd /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/lib/ext
$ sudo wget http://www.bouncycastle.org/download/bcprov-jdk15on-159.jar
$ sudo vim /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/lib/security/java.security
#
# List of providers and their preference orders (see above):
#
security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
+ security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider
# the NSS security provider was not enabled for this build; it can be enabled
# if NSS (libnss3) is available on the machine. The nss.cfg file may need
$ ./dependency-check/bin/dependency-check.sh -f XML -o ./result.xml -s /web/current/api/current --project dev-api -l ./owasp.log
[ERROR] Exception from bundle-audit process: java.io.IOException: Cannot run program "bundle-audit" (in directory "/tmp/dctemp668de20e-5168-4592-ada8-6b73ba425d34"): error=2,Il n'y a pas de tel fichier ou répertoire. Disabling Ruby Bundle Audit Analyzer
J'ai eu une erreur, mais l'erreur était parce que j'utilisais Ruby dans l'environnement à analyser, cet audit bundle n'a pas pu être exécuté.
https://rubygems.org/gems/bundler-audit
Donc, maintenant, vous devriez avoir résolu l'erreur de titre.
En outre, les paramètres d'audit de l'ensemble sont également décrits. Est-ce facile.
$ sudo gem install bundler-audit
Remplacez la destination de sortie du résultat par /tmp/result.xml
$ ./dependency-check/bin/dependency-check.sh -f XML -o /tmp/result.xml -s /web/current/api/current --project dev-api -l ./owasp02.log
Cela s'est terminé normalement.
c'est tout.