Partons sur des petits rappels historiques teintés de parano :
- le GPS, utilisation civile, origine militaire
- ARPAnet, utilisation civile, origine scientifique à portée militaire
- cryptographie, origine militaire
Les équipements disponibles dans le domaine militaire sont, constamment, en avance sur ce qui est utilisé dans le civil.
On peut à ce sujet s'intéresser de plus près à la NSA et à ses pratiques [1].
Pour rappel l'une de leurs techniques consiste à modifier les firmwares des disques [2] pour injecter des modules kernel dans différentes versions de Windows.
Rien ne les empêche, si ça n'est déjà fait, de s'attaques aux kernels linux et faire la même.
Ça me semble pas bien sorcier de surcharger la libc pour altérer un tout petit peu les calls à exec() et execve().
Mais la machine end-user, c'est pour du ciblé hein, voyons plus large !
Les routeurs, allez on va prendre Cisco ils en vendent plein [3].
Tu t'en fous, t'as des Juniper t'es safe… ah bah non [4].
Vous vous demandez où je veux en venir avec ça ?
C'est très simple, pour quelqu'un de déterminé et avec des ressources suffisantes, TLS ne vous protègera pas plus qu'un parapluie en pleine tempête.
Alors oui, c'est toujours mieux d'utiliser TLS parce que ça protège du gros des attaques, mais c'est pas non plus le miracle de sécurité auquel on voudrait nous faire croire.
Même les petits kékés qui se croient safe derrière leur service payant de VPN IPSEC oublient ce fait fondamental, leur machine a déjà été infectée, au boot, et sans qu'une quelconque réinstallation ou solution antivirus ne règle le problème.
Pour répondre à cette question de fond "est-ce que les numéros de carte passent en clair ?", la réponse est non.
Déjà parce qu'en dépit des problèmes liés à SSL/TLS ça serait débile, et ensuite parce que de toutes façons si on veut garder notre certif bah on n'a pas le choix ;)
On peut légitimement se demander "mais ça se trouve CF ils déchiffrent, et ensuite ils font transiter en clair dans leur infra".
Et oui, c'est possible.
C'est possible, mais si c'est fait, ça l'est avec l'accord de leur QSA pour la certif PCI-DSS.
Et à partir de ce moment, il n'y a pas grand chose que l'on puisse faire.
Au surplus, pour reverse proxy les requêtes vers notre propre infra, ils doivent re-chiffrer la connexion parce qu'on n'accepte pas l'HTTP cleartext.
En ce sens, recevoir en chiffré, déchiffrer dans leur infra, puis re-chiffrer pour nous reverse proxy la requête, c'est gâcher de la CPU.
Et à priori, quand tu veux faire des $$ (parce qu'après tout CF c'est pas non plus une asso à but caritatif hein), tu essayes de gâcher le moins possible.
Lisez les exigences de la certif, c'est particulièrement intéressant.
Vous le verrez, c'est tout autant contraignant…
On doit isoler physiquement les bécanes, tout chiffrer, tout compartimenter, tout logguer, utiliser des postes de travail certifiés…
Vous vous doutez que le choix d'utiliser CF a été fait en connaissance de cause.
Oui, ils pourraient intercepter les PANs, tout comme oui, je pourrais également intercepter les PANs.
Mais ils ont un business model à tenir, et moi j'ai un taf à garder.
Enfin, Thib, en ce qui concerne les solutions anti-DDoS et le fait de se prémunir directement au niveau IP. D'une part, c'est fait, on a des solutions en place dans ce sens.
D'autre part, la seule vraie solution pour être vraiment safe contre de la grosse DDoS, c'est de passer par des centres de scrubbing spécialisés.
Et pour passer par ces centres, le prestataire technique doit annoncer tes préfixes à ta place.
Et le jour où ils leak 200k routes à cause d'une erreur de config [5], bah les autres transitaires coupent la session avec eux, et comme c'était les seuls à t'annoncer tu t'es fait self DoS.
Malheureusement rien n'est parfait, et on fait tous du mieux qu'on peut.
Dites-vous bien que, aussi légitimes que soient vos questions, au final nous on a un seul objectif, c'est de sécuriser les PANs, pour contenter nos différents auditeurs, mais aussi les organismes légaux (genre la Banque de France).
En ce qui concerne ta première question, oui je le peux, et je le fais :
Cloudflare est certifié PCI-DSS.
Si l'on ne croit plus en la certification PCI-DSS et à son adhérence par les entités qui ont obtenu leur AOC, délivrée par des assesseurs certifiés par Visa, Mastercard et compagnie, alors on remet tout le système en question.
Ça revient au même que de remettre en question les root CA et l'utilisation de TLS.
En ce qui concerne ton second point, la conformité à PCI-DSS interdit formellement :
- le transit, en clair, de Primary Account Numbers, à savoir de numéros de carte
- le stockage, en clair, d'un PAN
- le stockage, sous quelque forme qu'il soit, du CVV
Ainsi, non seulement les numéros de carte sont obligatoirement transmis de manière chiffrée, mais leur stockage est également soumis à régulation, à savoir un chiffrement double en utilisant 2 clés possédées par des personnes physiques différentes.
J'ajouterais qu'il est interdit de logguer les numéros de carte, à défaut de faire subir à ces logs les mêmes contraintes de double chiffrement.
Enfin et pour en finir sur la sécurité, la certification exige que soient menés chaque trimestre :
- un scan externe des infras, par un ASV (ex, qualys)
- un scan interne des infras, via un outil répondant aux exigences PCI (ex, Nessus)
- une revue des règles firewall
- une revue du fonctionnement des caméras
- une revue des ports réseau et VLANs par lesquels transitent des PANs
Pour rebondir sur "des infras non contrôlées", le problème reste entier, utilisation de Cloudflare ou non :
- akamai ? même deal
- hébergement chez online ? même deal, tu passes par leur AS et leur matos réseau
- hébergement en propre ? même deal quand même, t'es pas un tier1 tu dois forcément passer par un transitaire quelconque, et mécaniquement, ses équipements réseau
Pour ce qui est de ton dernier point, je te signale quand même que c'est OP qui sort un article avec des faits fondamentalement incorrects, et que ces derniers ne peuvent rester sans réponse.
Aux dernières nouvelles on vend pas des ours en peluche, on traite des millions de transactions bancaires, l'impact en termes d'image n'est pas le même.
Sous-entendre que CF espionne les clients HiPay est dommageable pour la réputation des deux entités, et basé sur de la pure spéculation.
On n'est pas au JT à essayer de faire de l'audimat à tout prix là, on essaye de discuter posément de problématiques techniques.
Oui, CF pourrait intercepter les numéros de carte, au même titre que Akamai, Amazon, ou n'importe qui d'autre dont les équipements servent à un moment ou un autre pour faire transiter les données.
Non, CF ne le fait pas car ils subissent tout comme les autres entités certifiées PCI, un audit annuel au cours duquel leurs logs sont épluchés, leurs configurations vérifiées, leurs équipes auditées.
C'est aussi simple que ça, quand on est pas sûr de ses infos, il ne faut pas propager de fausses rumeurs, ce qu'a fait OP sans chercher à approfondir sa réflexion, ou tout simplement à contacter les équipes techniques pour avoir des réponses à ses questions.
C'est pourtant la base de toute entreprise vaguement journalistique (et pense bien qu'écrire un article à portée publique en est une), que de s'assurer de la véracité des informations que l'on poste.
Nous tenons à la disposition de quiconque la demande l'Attestation Of Compliance PCI-DSS délivrée à HiPay.
Cette seule certification, régie par les grands noms du secteur bancaire [1], suffit à elle seule à confirmer l'intégrité des données traitées par la plateforme.
"Prestataire de paiement : HiPay (et ce n'est pas que la vitrine, les codes de carte bleu, etc. passent bien par CloudFlare !)"
Tu es en train de proclamer haut et fort que CF se pose en MITM sur une infra de paiement que tu ne connais pas, pour une société que tu ne connais pas, et dans un contexte que tu ne connais pas.
Premièrement, CF a été choisi pour faire office de frontal contre les attaques volumétriques et autres script kiddies, tu m'excuseras mais on a pas tous 8x40gb d'uplink.
Deuxièmement, que le prestataire technique choisi soit CF, tartampion ou TamaireInc, les numéros de CB passent toujours sur les interwebs , via des AS hors de ton contrôle et des équipements hors de ton contrôle.
Si a un moment donné tu as cru que le TLS apportait ne serait-ce qu'une once de sécurité, c'est peut être le moment de te re pencher sur le sujet.
On n'a pas opté pour l'option de tirer des lignes X25 avec chaque client, on s'est dit que c'était peut être un peu overkill.
Troisièmement, HiPay est certifié PCI-DSS depuis 2013 (CF est également certifié PCI-DSS d'ailleurs).
Je t'invite à jeter un oeil rapide à la liste des requirements dressés par le Council pour avoir son attestation de compliance.
Tu as sûrement une alternative viable techniquement et économiquement, envoie ton CV et on en parlera pendant ton entretien.
Potasse bien le sujet hein ;)
[^] # Re: faut arrêter de tout diaboliser
Posté par dam23 . En réponse au journal CloudFlare au milieu. Évalué à 2.
Partons sur des petits rappels historiques teintés de parano :
- le GPS, utilisation civile, origine militaire
- ARPAnet, utilisation civile, origine scientifique à portée militaire
- cryptographie, origine militaire
Les équipements disponibles dans le domaine militaire sont, constamment, en avance sur ce qui est utilisé dans le civil.
On peut à ce sujet s'intéresser de plus près à la NSA et à ses pratiques [1].
Pour rappel l'une de leurs techniques consiste à modifier les firmwares des disques [2] pour injecter des modules kernel dans différentes versions de Windows.
Rien ne les empêche, si ça n'est déjà fait, de s'attaques aux kernels linux et faire la même.
Ça me semble pas bien sorcier de surcharger la libc pour altérer un tout petit peu les calls à exec() et execve().
Mais la machine end-user, c'est pour du ciblé hein, voyons plus large !
Les routeurs, allez on va prendre Cisco ils en vendent plein [3].
Tu t'en fous, t'as des Juniper t'es safe… ah bah non [4].
Vous vous demandez où je veux en venir avec ça ?
C'est très simple, pour quelqu'un de déterminé et avec des ressources suffisantes, TLS ne vous protègera pas plus qu'un parapluie en pleine tempête.
Alors oui, c'est toujours mieux d'utiliser TLS parce que ça protège du gros des attaques, mais c'est pas non plus le miracle de sécurité auquel on voudrait nous faire croire.
Même les petits kékés qui se croient safe derrière leur service payant de VPN IPSEC oublient ce fait fondamental, leur machine a déjà été infectée, au boot, et sans qu'une quelconque réinstallation ou solution antivirus ne règle le problème.
Pour répondre à cette question de fond "est-ce que les numéros de carte passent en clair ?", la réponse est non.
Déjà parce qu'en dépit des problèmes liés à SSL/TLS ça serait débile, et ensuite parce que de toutes façons si on veut garder notre certif bah on n'a pas le choix ;)
On peut légitimement se demander "mais ça se trouve CF ils déchiffrent, et ensuite ils font transiter en clair dans leur infra".
Et oui, c'est possible.
C'est possible, mais si c'est fait, ça l'est avec l'accord de leur QSA pour la certif PCI-DSS.
Et à partir de ce moment, il n'y a pas grand chose que l'on puisse faire.
Au surplus, pour reverse proxy les requêtes vers notre propre infra, ils doivent re-chiffrer la connexion parce qu'on n'accepte pas l'HTTP cleartext.
En ce sens, recevoir en chiffré, déchiffrer dans leur infra, puis re-chiffrer pour nous reverse proxy la requête, c'est gâcher de la CPU.
Et à priori, quand tu veux faire des $$ (parce qu'après tout CF c'est pas non plus une asso à but caritatif hein), tu essayes de gâcher le moins possible.
Lisez les exigences de la certif, c'est particulièrement intéressant.
Vous le verrez, c'est tout autant contraignant…
On doit isoler physiquement les bécanes, tout chiffrer, tout compartimenter, tout logguer, utiliser des postes de travail certifiés…
Vous vous doutez que le choix d'utiliser CF a été fait en connaissance de cause.
Oui, ils pourraient intercepter les PANs, tout comme oui, je pourrais également intercepter les PANs.
Mais ils ont un business model à tenir, et moi j'ai un taf à garder.
Enfin, Thib, en ce qui concerne les solutions anti-DDoS et le fait de se prémunir directement au niveau IP.
D'autre part, la seule vraie solution pour être vraiment safe contre de la grosse DDoS, c'est de passer par des centres de scrubbing spécialisés.
Et pour passer par ces centres, le prestataire technique doit annoncer tes préfixes à ta place.
Et le jour où ils leak 200k routes à cause d'une erreur de config [5], bah les autres transitaires coupent la session avec eux, et comme c'était les seuls à t'annoncer tu t'es fait self DoS.
Malheureusement rien n'est parfait, et on fait tous du mieux qu'on peut.
Dites-vous bien que, aussi légitimes que soient vos questions, au final nous on a un seul objectif, c'est de sécuriser les PANs, pour contenter nos différents auditeurs, mais aussi les organismes légaux (genre la Banque de France).
[1] http://www.theregister.co.uk/2015/03/12/nsas_on_drugs_infosec_bods_unveil_space_grade_malware/
[2] http://www.theregister.co.uk/2015/02/17/kaspersky_labs_equation_group/
[3] http://www.infoworld.com/article/2608141/internet-privacy/snowden--the-nsa-planted-backdoors-in-cisco-products.html
[4] https://gigaom.com/2013/12/29/nsas-backdoor-catalog-exposed-targets-include-juniper-cisco-samsung-and-huawei/
[5] http://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/
[^] # Re: faut arrêter de tout diaboliser
Posté par dam23 . En réponse au journal CloudFlare au milieu. Évalué à 7.
En ce qui concerne ta première question, oui je le peux, et je le fais :
Cloudflare est certifié PCI-DSS.
Si l'on ne croit plus en la certification PCI-DSS et à son adhérence par les entités qui ont obtenu leur AOC, délivrée par des assesseurs certifiés par Visa, Mastercard et compagnie, alors on remet tout le système en question.
Ça revient au même que de remettre en question les root CA et l'utilisation de TLS.
En ce qui concerne ton second point, la conformité à PCI-DSS interdit formellement :
- le transit, en clair, de Primary Account Numbers, à savoir de numéros de carte
- le stockage, en clair, d'un PAN
- le stockage, sous quelque forme qu'il soit, du CVV
Ainsi, non seulement les numéros de carte sont obligatoirement transmis de manière chiffrée, mais leur stockage est également soumis à régulation, à savoir un chiffrement double en utilisant 2 clés possédées par des personnes physiques différentes.
J'ajouterais qu'il est interdit de logguer les numéros de carte, à défaut de faire subir à ces logs les mêmes contraintes de double chiffrement.
Enfin et pour en finir sur la sécurité, la certification exige que soient menés chaque trimestre :
- un scan externe des infras, par un ASV (ex, qualys)
- un scan interne des infras, via un outil répondant aux exigences PCI (ex, Nessus)
- une revue des règles firewall
- une revue du fonctionnement des caméras
- une revue des ports réseau et VLANs par lesquels transitent des PANs
Pour rebondir sur "des infras non contrôlées", le problème reste entier, utilisation de Cloudflare ou non :
- akamai ? même deal
- hébergement chez online ? même deal, tu passes par leur AS et leur matos réseau
- hébergement en propre ? même deal quand même, t'es pas un tier1 tu dois forcément passer par un transitaire quelconque, et mécaniquement, ses équipements réseau
Pour ce qui est de ton dernier point, je te signale quand même que c'est OP qui sort un article avec des faits fondamentalement incorrects, et que ces derniers ne peuvent rester sans réponse.
Aux dernières nouvelles on vend pas des ours en peluche, on traite des millions de transactions bancaires, l'impact en termes d'image n'est pas le même.
Sous-entendre que CF espionne les clients HiPay est dommageable pour la réputation des deux entités, et basé sur de la pure spéculation.
On n'est pas au JT à essayer de faire de l'audimat à tout prix là, on essaye de discuter posément de problématiques techniques.
Oui, CF pourrait intercepter les numéros de carte, au même titre que Akamai, Amazon, ou n'importe qui d'autre dont les équipements servent à un moment ou un autre pour faire transiter les données.
Non, CF ne le fait pas car ils subissent tout comme les autres entités certifiées PCI, un audit annuel au cours duquel leurs logs sont épluchés, leurs configurations vérifiées, leurs équipes auditées.
C'est aussi simple que ça, quand on est pas sûr de ses infos, il ne faut pas propager de fausses rumeurs, ce qu'a fait OP sans chercher à approfondir sa réflexion, ou tout simplement à contacter les équipes techniques pour avoir des réponses à ses questions.
C'est pourtant la base de toute entreprise vaguement journalistique (et pense bien qu'écrire un article à portée publique en est une), que de s'assurer de la véracité des informations que l'on poste.
Nous tenons à la disposition de quiconque la demande l'Attestation Of Compliance PCI-DSS délivrée à HiPay.
Cette seule certification, régie par les grands noms du secteur bancaire [1], suffit à elle seule à confirmer l'intégrité des données traitées par la plateforme.
[1] https://www.pcisecuritystandards.org
# faut arrêter de tout diaboliser
Posté par dam23 . En réponse au journal CloudFlare au milieu. Évalué à -6.
"Prestataire de paiement : HiPay (et ce n'est pas que la vitrine, les codes de carte bleu, etc. passent bien par CloudFlare !)"
Tu es en train de proclamer haut et fort que CF se pose en MITM sur une infra de paiement que tu ne connais pas, pour une société que tu ne connais pas, et dans un contexte que tu ne connais pas.
Premièrement, CF a été choisi pour faire office de frontal contre les attaques volumétriques et autres script kiddies, tu m'excuseras mais on a pas tous 8x40gb d'uplink.
Deuxièmement, que le prestataire technique choisi soit CF, tartampion ou TamaireInc, les numéros de CB passent toujours sur les interwebs , via des AS hors de ton contrôle et des équipements hors de ton contrôle.
Si a un moment donné tu as cru que le TLS apportait ne serait-ce qu'une once de sécurité, c'est peut être le moment de te re pencher sur le sujet.
On n'a pas opté pour l'option de tirer des lignes X25 avec chaque client, on s'est dit que c'était peut être un peu overkill.
Troisièmement, HiPay est certifié PCI-DSS depuis 2013 (CF est également certifié PCI-DSS d'ailleurs).
Je t'invite à jeter un oeil rapide à la liste des requirements dressés par le Council pour avoir son attestation de compliance.
Tu as sûrement une alternative viable techniquement et économiquement, envoie ton CV et on en parlera pendant ton entretien.
Potasse bien le sujet hein ;)
Sans rancune.