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).
[^] # 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/