Gradle erreur : the trustAnchors parameter must be non-empty

Problème

Lancement de build gradle lance l'erreur suivante : 

Exception in thread "main" javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

at java.base/sun.security.ssl.Alerts.getSSLException(Alerts.java:214)

at java.base/sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1974)

at java.base/sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1926)

at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1909)

at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1436)

at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)

at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)

at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)

at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581)

at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)

at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245)

at org.gradle.wrapper.Download.downloadInternal(Download.java:66)

at org.gradle.wrapper.Download.download(Download.java:51)

at org.gradle.wrapper.Install$1.call(Install.java:62)

at org.gradle.wrapper.Install$1.call(Install.java:48)

at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:69)

at org.gradle.wrapper.Install.createDist(Install.java:48)

at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:107)

at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:61)

Caused by: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

at java.base/sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:89)

at java.base/sun.security.validator.Validator.getInstance(Validator.java:181)

at java.base/sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:330)

at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(X509TrustManagerImpl.java:180)

at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:192)

at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:133)

at java.base/sun.security.ssl.ClientHandshaker.checkServerCerts(ClientHandshaker.java:1947)

at java.base/sun.security.ssl.ClientHandshaker.certificateStatus(ClientHandshaker.java:1798)

at java.base/sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:276)

at java.base/sun.security.ssl.Handshaker.processLoop(Handshaker.java:1098)

at java.base/sun.security.ssl.Handshaker.processRecord(Handshaker.java:1026)

at java.base/sun.security.ssl.SSLSocketImpl.processInputRecord(SSLSocketImpl.java:1137)

at java.base/sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1074)

at java.base/sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)

at java.base/sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1402)

at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1429)

... 14 more

Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

at java.base/java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)

at java.base/java.security.cert.PKIXParameters.<init>(PKIXParameters.java:120)

at java.base/java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:104)

at java.base/sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:86)

... 29 more

Solution

Le problème venait de la version du jdk que j'utilise (version 10), après installation d'un jdk 8 et modification dans le path de la version de java le build se fait correctement. 

Mettre en place le plugin OWASP dependency check dans les projets SONAR

Problématique

Comment mesurer les potentielles failles de sécurité induites par les dépendances présentes dans le projet Java que je développe ? 

Solution 

Utilisation du plugin maven dependency check et du plugin sonar associé afin d'avoir un indicateur dans sonarqube :

Cette solution a été sur les version de composants suivants : 

• Sonarqube 1.1
• Maven 3.3.9
• dependency-check-maven 3.2.1
• sonar-maven-plugin 3.2
• sonar-dependency-check-plugin 1.1.0

Mise en place dans Maven

Dans le pom du projet ajouter les plugin suivants ainsi que les propriétés : 

<properties> ... <sonar.dependencyCheck.reportPath>${dependency.check.report.dir}/dependency-check-report.xml</sonar.dependencyCheck.reportPath> <sonar.dependencyCheck.htmlReportPath>${dependency.check.report.dir}/dependency-check-report.html</sonar.dependencyCheck.htmlReportPath> </properties> <build> ... <plugins> ... <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>sonar-maven-plugin</artifactId> <version>3.2</version> </plugin> <plugin> <groupId>org.owasp</groupId> <artifactId>dependency-check-maven</artifactId> <version>3.2.1</version> <configuration> <format>ALL</format> <outputDirectory>${dependency.check.report.dir}</outputDirectory> </configuration> <executions> <execution> <phase>package</phase> <goals> <goal>check</goal> </goals> </execution> </executions> </plugin> </plugins> </build>

Mise en place dans Sonarqube

1. Cloner le dépôt GIT :

git clone git@github.com:stevespringett/dependency-check-sonar-plugin.git

2. Se positionner sur le tag 1.1.0 :

git checkout 1.1.0

3. Builder le plugin :

mvn clean package

4. Dans le répertoire {project_dir}/sonar-dependency-check-plugin/target doit se trouver le plugin : 

sonar-dependency-check-plugin-1.1.0.jar

5. Copier le jar dans le répertoire {sonarqube_install}/extensions/plugins/ de sonarqube

6. Redémarrer Sonarqube

 Création du rapport contenant les vulnérabilités 

mvn clean package

Une fois le build effectué vous trouverez dans le /target du projet les fichiers dependency-check-report.* contenant les informations sur les vulnérabilités potentiellement présentes dans le projet.

 

 Création du rapport contenant les vulnérabilités dans sonar

Il faut que maven soit paramétré et configuré pour accéder à sonarqube.

mvn clean package sonar:sonar

Une fois le build effectué vous trouverez dans sonar un nouvel onglet sur le projet contenant le rapport html de l'analyse:

Dans 'Measures' se trouvera une nouvelle 'rubrique' OWASP-Dependency-Check (provenant du rapport xml) :

Pour aller plus loin

Il est tout a fait possible d'intégrer ce process dans une usine logicielle afin de bénéficier de l'intégration continue (au sein de jenkins par exemple) . 

Le plugin dependency check peut être paramétré pour terminer le build en erreur si une dépendance critique est détectée. 

Il est aussi possible sur SonarQube de créer des Quality gates contenant des contraintes de sécurité ce qui permettrait de détecter rapidement les failles de sécurité et statuer sur une éventuelle mise en production (selon criticité et choix entre les différents acteurs métiers) du produit logiciel. 

Retours sur les Devoxx France 2018

Cette année 2018 a encore été très enrichissante. Le nombre de sujets et de conférences étaient très nombreux. Les participants étaient aussi au rendez-vous, c'est simple si on traine un peu trop on se retrouve a chercher une solution de replis car la salle est pleine (sauf pour l'amphi qui hors keynotes est jamais plein a 100%).

Voici donc une partie de mes notes :

Les nouveautés autour de Java

Présenté par José Paumard & Rémi Forax, cette présentation nous a montré que le cycle de version des releases Java à vraiment accéléré (pour ceux qui l'avaient pas constaté). 

Java adopte maintenant un système de fork pour la gestion des version. 

Une fois qu'une version est release un fork est crée et ce fork devient la nouvelle version de java.

Le cycle de version est maintenant de 6 mois avec des version LTS. 

La prochaine version LTS étant Java 11 qui devrait sortir en septembre 2018.

Pour les personnes qui souhaiteraient effectuer une montée de version il vaut mieux attendre la version LTS plutôt que de passer de Java 8/9 vers java 10 par exemple. 

Etant personnellement pas encore passé a Java 10, j'ai découvert avec bonheur une nouvelle fonctionnalité : 

var users = new ArrayList<User>();

Oui oui, ça ressemble bien a du javascript :) 

Ce nouveau mot-clef ne s'utilise qu'au sein d'une fonction (Donc pas en tant que déclaration d'attribut)  et permet aussi de mettre dans une variable une fonction exemple : 

public List<String> getUrls () {return List.of("");} 

protected List<String> sendsUrls(){
  
 List<String> result = new ArrayList<>();
 var maFonction = getUrls();

 result.addAll(maFonction);
 return result;
}

Et voici rapidement les nouveautés a venir dans les prochaines versions (sous réserve de du suivi de la roadmap)


Java 11: var as type in Lamba Parameters Constant Dynamic Raw string Condy Java 12: Nouveaux Switch Preconditions : ex: Preconditions.requireNonNull(variable); Java 14: Sealed interface : defini l'ensemble des classes qui implementent l'interface. Generalized pattern maching

Authentification et autorisation décentralisée avec jwt et macaroo

Présenté par Julien Tanguy, lors ce cette présentation il a été rappelé la différence entre l'autorisation et l'authentification. 

L'authentification: Qui suis je ? 

L'autorisation: Qu'est je le droit de faire ? 

Pour ces deux notion , deux outils, JWT pour l'authentification et Macaroons pour les autorisation. 

Ces deux outils fonctionnent avec des tokens, une signature basée par un secret et une Payload. 

De ce que j'ai pu voir lors de la démo ça à l'air simple à utiliser 

Pour regarder plus près macaroons.io et jwt.io

Chaos Engineering

Présenté par Julien Gakic.

Dashboard à l'appui lors de la présentation, le chaos engineering est une pratique qui prends de plus en plus d'ampleur. 

Cette pratique vise à accroire la résilience des applications afin que la production soit toujours stable malgré les aléas du backend.

Le concept est d'introduire des dysfonctionnements sur la production (oui oui) afin de voir comment se comporte le système dans sa globalité.
Cela permet notamment de détecter les effets de bords d'un dysfonctionnement d'une application (une application qui impacterait par exemple une autre application qui n'aurait pas de lien direct avec celle en défaut).

Pour induire ces défauts sur la production il existe un outil qui s'appelle Chaos monkey. 

Enfin voici un site qui en parle plus en détail Principle of chaos.

Swagger 2 est mort vive openapi 3 !

Présenté par Sébastien Lecacheur

Voici ce qu'apporte Openapi 3 par rapport à Swagger 2:

Ajout de la balise servers (permets de mettre plusieurs liens d'envs par ex)
Ajout de la balise components

Ajout sheme et bearer format
Modification de la balise Basic qui devient http
Wilcard pour les codes http
Ajout de Content et media type
Possibilité de mettre plusieurs exemples
Support d'openid connect

Unassigned shards in Elasticsearch

Problème

Suite à la montée de version d'elasticsearch 5 vers 6 les shards n'étant pas alloués ce qui provoquait un dysfonctionnement du cluster elastic (j'avais 50% des shards alloués et donc un cluster 'Jaune' -> Pas fonctionnel)

Solution 

Il fallait simplement lire la doc de migration ...
Dans la doc de migration d'elastic 5 vers 6 on désactive le setting d'allocation de shards et a la fin de la migration il faut simplement la réactiver (une étape qui a du être oubliée). 

Sur un des nœud : 

curl -XPUT 'localhost:9200/_cluster/settings' -d
'{ "transient":
  { "cluster.routing.allocation.enable" : "all" 
  }
}'

Après avoir activé l'allocation, les shards ont été automatiquement activés et le cluster est passé en Vert (fonctionnel a 100%).

ElasticSearch 6 Systemd configuration memory lock pour Redhat 7

Problème

Suite à la mise a jour d'elasticsearch 5.x vers 6.x, il m'était impossible de démarrer le demon via systemd car j'avais l'erreur suivante :

[1] bootstrap checks failed
[1]: memory locking requested for elasticsearch process but memory is not locked

Solution

C'est tout simplement écrit dans la doc d'elasticsearch mais il faut fouiller un peu.

Dans le fichier de configuration systemd elasticsearch.service rajouter apres [Service] , LimitMEMLOCK=infinity:

[Service]
LimitMEMLOCK=infinity

Puis recharger le demon systemctl

sudo systemctl daemon-reload