Archive | Boulot

Playing with HTTPS

Je pose ça là !

L’inspection SSL/TLS, comment ca marche ?

J’ai un flux chiffré entre mon serveur et mon navigateur et je veux voir son contenu à l’ancienne (après je détaillerai comment on fait de l’inspection avec Kaspesrsky security endpoint chez mon employeur).

On va commencer par se mettre dan un cas favorable. Ce qui n’est pas le cas quand vous avez déployé HTTPS sur/etc/letsencrypt/options-ssl-apache.conf  votre site web comme un bourrin avec CERTBOT (mais merci quand même Let’s Encrypt).

Conf de base

Conf de base

Ca ne me plait pas, donc je vais désactiver Diffie-Hellman. Laissez moi faire du SSL 2.1 avec rien que du RSA, please  🙂

This task provides the procedure to disable Diffie-Hellman on Apache Servers by editing the SSLCipherSuite config option string in the ssl.conf or httpd.conf files.
Procedure

In Apache’s conf directory, locate file: ssl.conf or httpd.conf
Look for the SSLCipherSuite keyword string value:

Apache Cipher Suite

Apache Cipher Suite

To disable Diffie-Hellman, please insert « !EDH:!DHE:!DH:!ECDH » after the « ALL: » in the cipher spec.
This is an example and you will need to make sure you include it to all the variants of Diffie-Hellman to disable it on your web server.
For additional info: https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite

Repeat this edit in every SSL config section, if you are not using one global section.
Save the file.
Restart the web server for the changes to take effect.

Après quelques essais infructueux, il faut bien se rendre à l’évidence que cela ne fonctionne pas 🙂

On se dit donc que la conf de base a du être surchargée par CERTBOT. Bingo !

Real Cipher Suite Conf

Real Cipher Suite Conf

SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

Un petit nettoyage s’impose donc dans /etc/letsencrypt/options-ssl-apache.conf 

On va simplifier à :

SSLCipherSuite AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

Du coup, Wireshark confirme le changement de cipher:

I Love RSA

I Love RSA

Qualys SSL Labs nous confirme cette dégradation du niveau de sécurité :

SSL Labs

SSL Labs

« This server does not support Forward Secrecy with the reference browsers. Grade capped to B » … et oui, d’où l’intérêt de Diffie-Helmann !

En revanche pour « This server supports TLS 1.0 and TLS 1.1. Grade capped to B », on peut certainement faire quelquechose. En particulier, ajouter TLSv1 et TLSv1.1 de la liste des protocoles supportés dans /etc/letsencrypt/options-ssl-apache.conf 

C’est là que les choses sérieuses commencent.

Afin de déchiffrer le flux https, nous allons récupérer la clef privée de notre serveur Apache et la fournir à wireshark. En principe, c’est par ce genre de manipulations hasardeuses que nos précieuses clefs privés finissent dans la nature. En l’occurrence, pas vraiment de sensibilité pour cette plateforme de démo.

Le chemin vers la clef est renseigné dans /etc/letsencrypt/options-ssl-apache.conf 

Je décrirai bientôt ailleurs comment cette clef intervient dans une phase amont du chiffrement de flux. Elle sert juste à « calculer » la véritable clef de chiffrement symétrique du flx entre chacun des navigateurs qu se se connectent  notre serveur Apache.

Le serveur web est exposé directement sur internet et semble fonctionner correctement :

bzhits.fr

bzhits.fr

Pour faciliter la tâche aux attaquants, il expose via sa page index.php le contenu d’un phpinfo().  C’est un pauvre VPS chez OVH qui donne toute satisfaction. Il sert par ailleurs  récupérer des logs du bruit de l’internet…

Cadenas vert pour monsieur Noël, tout semble ok en termes de sécu.

phpinfo()

phpinfo()

Le certificat SSL ( que je n’aime pas cette appellation !!!) présenté à l’air de correspondre au serveur considéré, nous sommes tranquilles jusqu’au 31 décembre 2021.

Certificat X509

Certificat X509

Une première analyse brute du flux confirme un certain nombre d’évidences :

– l’appli répond normalement

– le flux est bien chiffré et débute par le traditionnel « TCP handshake »

– on fait du TLS1.2 over HTTP 1.1

– setup : wireshark (1.12.1) sur Debian intercepte mon interface wan avec filtre de capture sur l’IP du serveur (vsible dans l’entête de la fenêtre)

Capture réseau

Capture réseau

Afin qu’il puisse déchiffrer le flux, on va fournir la clef privée du serveur à Wireshark.

Plz, give me your Private Key

Plz, give me your Private Key

Pour le coup, j’ai crée un formulaire minimaliste (login.html) qui demande un identifiant et un mot de passe à un utilisateur pour le transmettre via requête POST à une page de traitement (login.php).

pwd leak

pwd leak

Grâce à l’interception TLS, on voit très bien passer les informations de connexion (marot / pwd).

Pour un truc plus propre dans Wireshark, préférez passer vos requêtes en ligne de commande via cUrl : curl -k -F « usr=marot » -F « pwd=password » « https://bzhits.fr/login.php »

CQFD step 1

CQFD step 1

Bon, maintenant que cela fonctionne avec touts les précautions précédentes, voyons comment s’adapter au cas où l’administrateur de votre site ait eu la bonne idée d’utiliser Diffie-Helmann. Car vous avez bien compris que si dans 3 mois ou dans 10 quelqu’un trouve votre clef privée et ressort des captures réseau, RIP la confidentialité.

Tout cela était déjà fort bien expliqué par Benjamin aka @vincib lors des confs mémorables « Il était une fois l’internet »

 

____________________________________________________________________________________

Pour pouvoir écrire ces quelques lignes, j’ai du réapprendre à surligner du texte dans une image avec The Gimp (p’tain je préfère snap/capture sous Windows), modifier les fichiers de traductions .po/.mo wordpress avec poEdit, retrouver l’accès ssh à ce vieux VPS chez OVH, appliquer les mises à jours Worpress sans faire de sauvegarde, réviser ma conf Apache / mod_ssl pour  pour les nuls…. Bref, ça m’a pris des plombes…

L’objectif initial de cet article était de proposer une explication sur un vieux chall root-me SSL – HTTP exchange qui était lui même une re-sucée d’un challenge qualif DEF CON préhistorique… et aussi de me servir de base pratique pratique pour une formation que je donnerai sous peu.

Pour aller plus loin, maintenant que vous avez compris le principe, je vous laisse trouver l’appliance sécu qui va bien pour faire la même chose de manière industrielle … dans le respect de la loi … et en accod avec votre perception de l’éthique.

J’espère que cela vous donnera aussi l’envie de lire les Recommandations de sécurité relatives à TLS de l’ANSSI téléchargeables à cette adresse : https://www.ssi.gouv.fr/uploads/2017/07/anssi-guide-recommandations_de_securite_relatives_a_tls-v1.2.pdf

 

Posted in Boulot, Clic0 commentaire

Public Key Cryptography Standards

base : https://en.wikipedia.org/wiki/PKCS / https://fr.wikipedia.org/wiki/Public_Key_Cryptographic_Standards

In cryptography, PKCS stands for « Public Key Cryptography Standards ». These are a group of public-key cryptography standards devised and published by RSA Security LLC, starting in the early 1990s. The company published the standards to promote the use of the cryptography techniques to which they had patents, such as the RSA algorithm, the Schnorr signature algorithm and several others. Though not industry standards (because the company retained control over them), some of the standards in recent years have begun to move into the « standards-track » processes of relevant standards organizations such as the IETF and the PKIX working-group.

Les PKCS (Public-Key Cryptography Standards), ou standards de cryptographie à clé publique, sont un ensemble de spécifications conçues par les laboratoires RSA en Californie. La société RSA Security est spécialisée dans les solutions de sécurité cryptographiques. Elle est également propriétaire de licences d’exploitations de plusieurs algorithmes (dont RSA avant l’expiration de son brevet le ). C’est pour ces raisons que la société a développé et promu les PKCS, permettant l’implantation des techniques de cryptographie à clé publique.

La société RSA Security n’est pas un organisme de normalisation, et pourtant, elle contrôle complètement l’élaboration et l’évolution des PKCS. L’appellation des PKCS comme standards au sens strict est donc abusive. Répondant à un réel besoin technique, les PKCS ont néanmoins été très largement adoptés par le milieu informatique. Le groupe de travail PKIX de l’IETF a depuis reformulé certains des PKCS dans des RFC, les standards Internet. L’abus de langage confondant le PKCS au lieu de la RFC correspondante est très répandu.

1- revenir sur la place de la cryprographie dans dans le cadre plus large de la cryptologie.

2- flash back sur l’histoire de l’entreprise RSA (https://fr.wikipedia.org/wiki/RSA_Security) ( y compris le leak de 2011)

3- faire une lecture croisée de ressources francophones et internationales

RSA Security

RSA Security

 

Version Nom Commentaires
PKCS#1 2.1 Standard de cryptographie RSA RFC 34471. Définit le chiffrement et la signature RSA (notamment les schémas de remplissage OAEP, PSS et PKCS1-v1.5).
PKCS#2 Obsolète Décrivait le chiffrement RSA de condensés de message, mais a été intégré dans PKCS#1.
PKCS#3 1.4 Standard d’échange de clés Diffie-Hellman
PKCS#4 Obsolète Décrivait la syntaxe de clé RSA, mais a été intégré dans PKCS#1.
PKCS#5 2.0 Standard de chiffrement par mot de passe cf. RFC 28982 (rendu obsolète par la RFC 80183) et PBKDF2.
PKCS#6 1.5 Obsolète Définissait les extensions de l’ancienne spécification de certificat X.509 v1.
PKCS#7 1.5 Standard de syntaxe de message cryptographique Cf. RFC 23154. Utilisé pour signer et/ou chiffrer des messages dans le cadre d’une infrastructure à clés publiques. Sert également à la transmission de certificats (notamment en réponse à un message PKCS#10). À l’origine de S/MIME, qui est désormais décrit sous le nom Cryptographic Message Syntax (CMS) dans la RFC 56525.
PKCS#8 1.2 Standard de syntaxe d’information de clé privée Cf. RFC 59586.
PKCS#9 2.0 Types d’attributs sélectionnés RFC 29857
PKCS#10 1.7 Standard de requête de certificat Cf. RFC 29868. Format des messages envoyés à une autorité de certification et demandant la signature d’une paire de clés.
PKCS#11 2.20 Interface de périphérique cryptographique (cryptoki) Une API définissant une interface générique pour périphérique cryptographique.
PKCS#12 1.0 Standard de syntaxe d’information personnelle Définit un format de fichier généralement utilisé pour stocker la clé privée et le certificat de clé publique correspondant en les protégeant par un mot de passe.
PKCS#13 Standard de Cryptographie sur les courbes elliptiques (En cours de développement)
PKCS#14 Générateur de nombres pseudo-aléatoires (En cours de développement)
PKCS#15 1.1 Standard de format d’information sur les périphériques cryptographiques Définit un standard permettant aux utilisateurs de périphériques cryptographiques de s’identifier auprès des applications, indépendamment de l’implantation de la cryptoki par l’application (PKCS #11) ou une autre API. La partie de cette spécification concernant les cartes IC a été intégrée dans le standard ISO/IEC 7816-15. [1] [archive]

#PKCS1 se prête très bien à l’illustration d’un des « standards »

Posted in Boulot, PKI, ICP, IGC0 commentaire

Le web en quelques dates

Au commencement, web (www) = HTTP + URL + HTML

Web 0.0 en 1989-1992 : WorldWideWeb:Proposal for a HyperText Project
Web 1.0 – An 05 après Tim Berners-Lee : TXT moche et interactivité faible via CGI
Web 2.0 – An 10 après Tim Berners-Lee : GUI riches, ergonomiques, interactivité et traitements asynchrones
Web 3.0 – An 20 après Tim Berners-Lee : UX, webservices et multicanal
Web x.x – An 30 après (pendant !) Tim Berners-Lee : API / JSON / websockets en microservices produits depuis un repo git par pipeline CI/CD

1992 : cookie
1993 : NCSA Mosaïc
1993 : ssl 1.0 (non implémenté)
1994 : ssl 2.0 (dans Netscape Communicator puis IE 2.0)
1995 : Amazon
1995 : <img … /> <form … /> <input…/ > HTML tags in HTML 2.0
1995 : Mocha (ancêtre de Javascript par Brandan Eich
1995 : Applet Java
1996 : Microsoft ActiveX
1996 : HTTP 1.0 RFC 1945
1996 : CSS
1997 : Macromedia Flash
1997 : HTTP 1.1 RFC 2816
1998 : XML et Ajax
1999 : TLS 1.0
1999 : de Yahoo-Altavista à Google
2000 : REST et les services web by Roy Fieldieng
2001 : OWASP
2003 : JSON par Douglas Crockford
2004-2010 : Youtube / Facebook / Twitter / Instagram
2011 : Web Socket Protocole RFC 6455
2012 : Let’s encrypt Project
2014 : HTTP 2.0 RFC 7540
2015 : JWT RFC 7519
2018 : TLS 1.3 RFC 8446
2018 : DNS over HTTPS RFC 8484

Posted in Boulot0 commentaire

Playing with bcrypt and Joomla

Juste pour poser là quelques détails sur le stockage sécurisé des mots de passe dans Joomla (cms php très courant).

Bref un truc avec lequel on joue un peu en TP, mais qui est aussi parfois bien utile quand on a perdu le mot de passe de l’unique compte d’administration du site (n’est-ce pas la Mairie de N….?, vieille mission Alliacom en 2010).

Si je jette un œil sur le contenu de ma table des utilisateurs Joomla, j’aperçois ce genre de chaînes de caractères dans les champs password :

$2y$10$OL0ibA8TKT.287zm4HPkYuKI/5CH0X1bMe9PyxPRjOxjeCSC/FOwm

On notera par ailleurs qu 2 utilisateurs avec le même mot de passe présenteront un hash différent, bref on est loin du pauvre MD5 sans sel utilisé il y a quelques années par Joomla.

On reconnaît un hash bcrypt par la présence en début de chaîne de  $2y dans ‘$2y$10$’, le $10 est le coût algorithmique, autrement dit 210 = 1 024 itérations.

Les 22 caractères suivants constituent le sel aléatoire. Les caractères qui complètent la chaîne composent le mot de passe hasché. Comme un petit schéma vaut mieux qu’un long discours :

brcypt

brcypt selon wikipedia

Pour plus de détails (tout public) sur bcrypt  : https://www.bcrypt.fr/questions

Et pour aller plus loin dans la compréhension : https://auth0.com/blog/hashing-in-action-understanding-bcrypt/

Et enfin pour faire quelques tests en ligne : https://bcrypt-generator.com/

La fonction crypt en php, fonctionne donc comme cela :

crypt($motdepasse, '$2y$10$'.randombytes(22));
playing with bcrypt and Joomla

playing with bcrypt and Joomla

http://micmap.org/php-by-example/man…ion.crypt.html

Exemple : password (très mauvaise idée de mot de passe)

$2y$10$.prE1BkZ87aPNnsKMTOSxe9pv8TQIhfBb2HZpSnBPfh.LeHgnaLD2

 

Cette fonction est par exemple utilisée dans Joomla la classe/méthdoe JUserHelper::hashPassword pour Joomla. Après étude, il est ainsi relativement simple de créer un fichier joomla-password-hash.php et de le placer à la racine de son site.

<?php
define(‘_JEXEC’, 1);
define(‘JPATH_BASE’, dirname(__FILE__));
require_once(JPATH_BASE . ‘/includes/defines.php’);
require_once(JPATH_BASE . ‘/includes/framework.php’);
echo « <strong>Password: </strong> » . JUserHelper::hashPassword(‘password’);

?>
https://api.joomla.org/cms-3/classes/JUserHelper.html

En résumé, le nombre d’itérations implique un calcul plus long et plus fastidieux pour les scripts de hacks et même si la base de données était piratée, cela me semble un peu plus difficile de retrouver le mot de passe… comme ce fut le cas l’année dernière pour dailymotion (ce service de video utilisent bcrypt également) : https://www.information-security.fr/…didentifiants/

L’implémentation d bcrypt a donné un peu plus de sécurité à Joomla, cela n’empêche pas d’imposer un minimum de caractères, mélange min/maj, caractères spéciaux aux mots de passe pour fonctionner un peu plus efficacement. Il faut éviter par exemple que les utilisateurs utilisent uniquement leur date d’anniversaire pour le mot de passe … (chercher « paradoxe des anniversaires » dans un moteur de recherche si vous aimez les probabilités )…

De plus, il y a aujourd’hui un marché de solutions complémentaires à connaître : MFA, double authentification (google authenticator et dérivé), sans mot de passe comme launchkey.com, par sms avec accountkit de facebook…

Posted in Boulot, Clic1 Commentaire

OpenShift Issue

OpenShift Playground

OpenShift Playground

Sad, no beeing able to assess OpenShift Playground 🙁

 

 

 

 

2 months later 🙁

openshift's answer 2021

openshift’s answer 2021 – Playground is dead

Posted in Boulot, Clic, Trop sérieux2 Comments

Solarwinds (solorigate, sunburst)

SolarWinds - Photographer: TRIPPLAAR KRISTOFFER/SIPA/AP

SolarWinds – Photographer: TRIPPLAAR KRISTOFFER/SIPA/AP

 Le sujet :

Voir page Wikipedia FR ou mieux Wikipedia EN

Raccourci :

Un vulgarisation du sujet grâce à une vidéo de 5mn de Romain du Marais

Les faits : « In an operation that cybersecurity experts have described as exceedingly sophisticated and hard to detect, the hackers installed malicious code in updates to SolarWinds’s widely used Orion software, which was sent to as many as 18,000 customers.

The malicious code provided the hackers access to the customers’ computer networks and, as clients around the world continue to comb their systems for signs of the Russian hackers, the list of victims is expected to grow. »

 

Chronologie :

Octobre 2019 : premiers essais à blanc de la méthode de distribution du malware

Mars 2020 : distribution de la backdoor

8 décembre 2020 : FireEye, par le biais d’un article de blog de son CEO Kevin Mandia communique sur le hack dont elle vient d’être victime avec pour conséquence le vol d’une partie des outils utilisés par ses Red Teams.

Reuters et les agences de presse généralistes relaient l’information : U.S. cybersecurity firm FireEye discloses breach, theft of internal hacking tools

13 décembre 2020 : communication coordonnée de FireEye, solarwinds, Microsoft et du gouvernement américain.

 

Premiers détails:

NextImpact – 23 décembre 2020
Piratage de SolarWinds : un ancien salarié avait alerté, en vain
D’après le très bon article original de Bloomberg du
SolarWinds Adviser Warned of Lax Security Years Before Hack by

 

Communication de crise : SolarWinds spokesperson said in a statement, “Our top priority is our work with our customers, our industry partners and government agencies to determine whether a foreign government orchestrated this attack, best understand its full scope, and to help address any customer needs that develop. We are doing this work as quickly and transparently as possible. There will be plenty of time to look back and we plan to do that in a similarly transparent way.”

In addition, the company said it is collaborating with law enforcement and “will continue gathering all relevant information to ensure an incident like this does not happen again.

 

Les acteurs :

Kevin Thompson, solarwinds’s chief executive officer, former securty adviser at solarwid

Ian Thornton-Trump, chief information security officer at threat intelligence firm Cyjax Ltd

Tim Brown former chief technology officer at Dell Security, current vice president of security architecture

Vinoth Kumar Cybersecurity expert who discovered FTP server credential on gitHub

Former internal langue de pute, ex solarwind : A former SolarWinds employee, who worked as a software engineer at one of the company’s U.S. offices, said SolarWinds appeared to prioritize the development of new software products over internal cybersecurity defenses.

Jake Williams, aka monsieur-je-sais-tout, a former hacker for the U.S. National Security Agency who is now president of cybersecurity firm Rendition Infosec, said technology companies such as SolarWinds that build and produce computer code often “don’t do security well.”

 

Les victimes :
At Least 200 Victims Identified in Suspected Russian Hacking, dont :

 

Les affreux :

Alors, Dark Halo ou bien  APT29 (aka Cozy Bear), un groupe de hackers lié au SVR (Служба внешней разведки Российской Федерации, retranscrit en Sloujba vnechneï razvedki Rossiskoï Federatsi2 – Service des renseignements extérieurs de la fédération de Russie – Russian Foreign Intelligence Service) ?

Joe Słowik ⛄ @jfslowik · 17 déc.

Joe Słowik ⛄ @jfslowik – 17 déc.

 

Un peu de technique :

Très bon article intégrant pas mal de détails techniques compréhensibles par ma mère sur l’attaque dans l’article The SolarWinds cyberattack: The hack, the victims, and what we know

Pour aller, plus loin : le technical write-up de Microsoft

SolarWinds supply chain attack Source: Microsoft

SolarWinds supply chain attack
Source: Microsoft

 

Conclusion de Costin Raiu (Kaspersky GREAT) :

Even if SolarWinds had robust cybersecurity practices, however, it might not have deterred the alleged Russian hackers, who U.S. authorities described as highly skilled, patient and well resourced, demonstrating “complex tradecraft” in their attacks.

“The reality is that sophisticated threat actors, no matter how good the defenses, will eventually succeed,” said Costin Raiu, director of global research and analysis at the cybersecurity firm Kaspersky. “If the cost justifies the effort, the breach will happen.”

 

 

Mises à jour :

02/01/2020 : The New-York Times : As Understanding of Russian Hacking Grows, So Does Alarm

04/01/2020 : Detecting Supernova Malware using Splunk

05/01/2020 : SolarWinds Hit with Securities Class Action Over Statements in Run-Up to Cyberattack on Fed. Government

05/01/2020 : FBI, CISA, NSA Officially Blame Russia for SolarWinds Cyber Attack

Russia loves solarwinds

solarwinds

Posted in Boulot13 Comments

Notes Splunk 2020

Splunk

Splunk

 

 

 

 

 

 

 

 

 

Quelques conseils ici pour réaliser nos tests..Installation et configuration de Splunk

C’est fou ce que ce petit outil me dit de vous.

J’ai caché 2 ou 3 trucs rigolos sur ce site, saurez-vous les découvrir ?

 

Posted in Boulot0 commentaire

Protégé : HTTP authentication

Cette publication est protégée par un mot de passe. Pour la voir, veuillez saisir votre mot de passe ci-dessous :

Posted in BoulotSaisissez votre mot de passe pour accéder aux commentaires.

Protégé : RSA public key : Behind the scene

Cette publication est protégée par un mot de passe. Pour la voir, veuillez saisir votre mot de passe ci-dessous :

Posted in Boulot, CryptoSaisissez votre mot de passe pour accéder aux commentaires.

TLS setup for Apache Tomcat

Very first thing : Read That F*** Manual !

$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA

and specify a password value of « whatYouWantButNotChangeIt ».

keystore

keystore

 

 

 

 

 

 

 

 

 

 

 

 

 

Edit your server.xml file, beware that commented examples provided could be very far from what youy need :

<!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
<Connector
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           port="8443" maxThreads="200"
           scheme="https" secure="true" SSLEnabled="true"
           keystoreFile="${user.home}/.keystore" keystorePass="changeit"
           clientAuth="false" sslProtocol="TLS"/>


<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
keystoreFile="/root/.keystore"
keystorePass="***********"
clientAuth="false" sslProtocol="TLS">

Posted in Boulot0 commentaire