CDNs’ Dark Side: Security Problems in CDN-to-Origin Connections
Pourquoi ce travail est dans la base
Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.
Notice bibliographique
Résumé
Content Delivery Networks (CDNs) play a vital role in today’s Internet ecosystem. To reduce the latency of loading a website’s content, CDNs deploy edge servers in different geographic locations. CDN providers also offer important security features including protection against Denial of Service (DoS) attacks, Web Application Firewalls (WAFs), and recently, issuing and managing certificates for their customers. Many popular websites use CDNs to benefit from both the security and the performance advantages. For HTTPS websites, Transport Layer Security (TLS) security choices may differ in the connections between end-users and a CDN (front-end or user-to-CDN), and between the CDN and the origin server (back-end or CDN-to-Origin). Modern browsers can stop/warn users if weak or insecure TLS/HTTPS options are used in the front-end connections. However, such problems in the back-end connections are not visible to browsers or end-users, and lead to serious security issues (e.g., not validating the certificate can lead to MitM attacks). In this article, we primarily analyze TLS/HTTPS security issues in the back-end communication; such issues include inadequate certificate validation and support for vulnerable TLS configurations. We develop a test framework and investigate the back-end connection of 14 leading CDNs (including Cloudflare, Microsoft Azure, Amazon, and Fastly), where we could create an account. Surprisingly, for all the 14 CDNs, we found that the back-end TLS connections are vulnerable to security issues prevented/warned by modern browsers; examples include failing to validate the origin server’s certificate, and using insecure cipher suites such as RC4, MD5, SHA-1, and even allowing plain HTTP connections to the origin. We also identified 168,795 websites in the Alexa top 1 million that are potentially vulnerable to Man-in-the-Middle (MitM) attacks in their back-end connections regardless of the origin/CDN configurations chosen by the origin owner.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,003 | 0,002 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,002 |
| Études des sciences et des technologies | 0,001 | 0,000 |
| Communication savante | 0,001 | 0,002 |
| Science ouverte | 0,001 | 0,001 |
| Intégrité de la recherche | 0,000 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle