Générer une requête pour un certificat SSL (pas 1)
Traiter des données confidentielles – et maintenant?
Vous bien sûr l'auriez vu assez souvent: Votre lecteur Web montre un symbole
cadenas à côté du lien de la page demandée, qui commence en outre avec
https://.
Il est monnaie courante pour le commerce online et des transactions bancaires,
mais il apparaît aussi sur des sites qui ne traitent aucunes données
confidentielles, mais avec la justification qu'il ne concerne pas personne
qu'on fait sur le site en question. Vous allez aussi le trouver sur ce site,
robidu.de, lorsque vous visitez certaines pages sur
ce domaine, par exemple cette page.
Ce que vous utilisez momentairement est une connexion chiffrée et sécurisée qui
est et antiécoute et résistante contre des essais de manipulation.
Pour garantir ces critères d'une connexion chiffrée des certificats sont
utilisés qui provisionnent des clés nécessaires pour chiffrer le train de
données entre votre lecteur Web et le serveur de la site Web et fournir des
informations sur le serveur visité. On y peut facilement deviner ce à qu'on a
affaire.
Suivre des données indésiré!
Des transactions commerciales ou administratives même si la protection du
secret de la correspondance (oui, le courrier électronique est encore le
courrier!) sont des raisons légitimes pour utiliser les technologies de
chiffrage. On y transfère en définitive des données qui ne concernent pas
personne sauf l'utilisateur et éventuellement le destinaire. Mais il y a assez
d'escrocs et débiles qui voient ça différemment et de préférence veulent suivre
tout – mais il n'est absolument pas le moment concernant des données
définitivement confidentielles.
Par contre on pourrait argumenter qu'on écrase une mouche avec un marteau si on
utilise la cryptographie sur des sites qui n'offrent rien que des données
publiquement accessibles. Mais on ne peut pas dénier la raison que ce qu'on
fait sur des sites en question ne concerne personne (mot-clé sphère privée),
mais la question se pose si on le ne voit pas trop grand.
Le chiffrement a encore besoin de temps de calcul, parce qu'il faut chiffrer
le train de données par le transmetteur et le déchiffrer par le receveur. On y
pourrait argumenter que ce temps est négligeable en raison des ordinateurs
puissants de plus en plus, mais on ne peut pas entièrement éliminer ce
retardement. En outre il obligatoirement fait des criminels entrer en lice,
parce qui essaient le cambriolage sur le serveur en question ou présument qu'il
y a des données confidentielles qu'ils puissent utiliser pour faire mal à la
partie concernée – ou ils conjecturent qu'il y a des logiciels administratives
ou de contrôle, etc., dont points faibles ils peuvent exploiter pour faire le
cambriolage et ensuite employer le serveur pour des activités illégales.
J'ai donc pris la décision de sanctuariser exactement les zones dans lesquelles
des données confidentielles sont transmises, mais les zones dans lesquelles il
n'y a rien de tel qui a lieu restent non chiffrées. Premièrement ce site n'a
pas besoin de se cacher, et secundo, à mon goût il y a des problèmes pires à
une connexion non chiffrée, soit la réclame qui est intégrée dans des sites Web
ou des autres éléments suivants (qu'est la raison pourquoi vous n'allez rien de
pareil trouver ici).
Certificat signé par soi-même ou non?
Les deux variantes ont leurs respectives avantages et désavantages. Un
certificat signé par soi-même ne coûte rien, mais normalement il fonctionne
aussi bien que tout certificat qu'on obtenir d'un organisme de certification.
Mais son désavantage est qu'il paraît fiable dans les cas les plus rares et
donc un site auquel on transmet des informations confidentielles est
normalement regardé avec beaucoup de soupçon – surtout un lecteur Web va
normalement signaler le problème et déconseiller à vous de faire l'accès à
ce site. Mais tel certificat sert idéalement des essais et rendre des activités
de vos visiteurs méconnaissable.
Mais lorsque vous voulez traiter des données confidentielles, il est bon
conseil d'utiliser un certificat obtenu d'un organisme de certification
indiqué. Ça coûte peu ou prou, dépendant du type du certificat, mais
premièrement le lecteur Web ne va pas se plaindre duquel, et secondement
l'organisme de certification mandaté confirme par le certificat qu'il est
vraiment le serveur qu'il prétend être, cependant les certificats simples ne
fournissent aucunes informations sur l'opétateur du site. Ils sont normalement
les certificats plus puissants qui les fournissent, mais ils coûtent
considérablement plus chers.
Validation du domaine vs. validation de l'identité vs. validation élargie
Dans le cas le plus simple pendant délivrer un certificat le domaine pour
lequel il est demandé est vérifié. Ceci peut être effectué comparativement
facilement, pour que la plupart de cette procédure ait lieu automatisée, et
elle s'est normalement effectuée pendant un jour ouvrable.
Il est différent pour des certificats qui confirment l'identité d'opérateur du
site – quelque chose bien recommandée pour des gens d'affaires, parce qu'il
établit une plus bonne base d'une relation de confiance. Mais il y a encore un
problème: Des proxys SSL.
Ce qui paraît bénin au premier coup d'œil, mais en réalité c'est pas de la
tarte: Il peut intercepter une connexion SSL et la déchiffrer avant que les
données soient rechiffrées et envoyées à leur originelle destination
(veuillez
le lire sur grc.com). Plusieurs certificats ne vous aident plus dans ce
cas, parce qu'il vous illusionne que vous êtes connectés au site désiré que
vous vouliez visiter sans station intermédiaire, et au premier coup d'œil il
paraît normal. Mais en y regardant de plus près on pourra rapidement déterminer
des différences, en particulier en comparant les empreintes digitales des
certificats utilisés. Le certificat truqué a obligatoirement une empreinte
digitale différent comme lequel utilisé sur le site visité, et
grc.com vient à votre aide encore une fois. Sur la
page référencée précédemment entrez l'adresse du serveur désiré et ensuite
comparez l'empreinte digitale dérivée sur la page-là à laquelle du certificat
montré à votre lecteur Web. Lorsque vous découvrez des différences, la
connexion est interceptée par au moins un proxy SSL.
Les affaires deviennent plus facile lorsque la validation élargie est utilisée,
parce qu'et le Firefox et le Chrome définitvement vont signaler que tout est
d'accord si la connexion n'est pas interceptée. Lorsque le lecteur Web est
montré un certificat qui fournit la validation élargie, il montre un champ vert
qui contient un symbole cadenas à gauche de l'adresse du site au lieu d'un
symbole cadenas simple, dans lequel le propriétaire du certificat est indiqué.
Pour qu'on ne peut contrefaire cela définitivement (les deux sont open-source,
donc leurs codes source sont disponibles pour inspecter par tout le monde), un
site qui utilise un certificat fournissant la validation élargie ne va pas
montrer le champ vert lorsque la connexion est interceptée, parce qu'un
certificat totalement différent est montré au lecteur Web.
Parce que ni Opera ni Safari ne sont open-source, on ne poourrait pas suivre à
cent pour cent comment ils se comportent dans ce cas, mais on peut
sous-entendre momentairement qu'ils appliquent le même maniement comme Firefox
et Chrome.
Il est seulement l'Internet Explorer qui fait tache – encore une fois – parce
qu'il est possible de modifier la base de données de l'IE avec un outil à une
manière qu'il acceptera des certificats signés par quelconque organisme de
certification comme des certificats fournissant de la validation élargie, et
l'indication de la validation élargie donc n'est pas expressive.
Plus
d'informations à obtenir sur grc.com.