Om du har arbetat med cybersäkerhet någon gång har du förmodligen hört den gyllene regeln "Använd alltid HTTPS i produktion". Det är det viktigaste rådet för att säkra webbkommunikation, och av goda skäl krypterar det data under överföring. Med andra ord skyddar HTTPS känslig information från avlyssning. Men när det gäller Public Key Infrastructure (PKI), särskilt för att hantera certifikatåterkallelse, gäller inte den regeln alltid. På Encryption Consulting använder vi vår omfattande erfarenhet av att arbeta med Fortune 500-företag, federala entreprenörer och molnbaserade företag för att designa robusta PKI-system. En fråga vi har fått ofta är: "Borde vi inte använda HTTPS för våra återkallningsslutpunkter, som CRL:er och OCSP?”
Svaret kanske överraskar dig: ofta i dessa fall gör HTTPS mer skada än nytta. Låt oss dyka ner i varför HTTP kan vara det smartare valet i PKI för återkallningsslutpunkter.
Återkallningsinformationen är digitalt signerad av CA
När ett certifikat återkallas, till exempel på grund av en komprometterad nyckel eller ett policybrott, kommer den utfärdande parten Certifikatmyndighet (CA) måste meddela förlitande parter. Detta sker genom två huvudsakliga metoder. Certifikatåterkallningslistor (CRL:er) är signerade filer som publiceras regelbundet och listar alla certifikat som har återkallats. Alternativt tillhandahåller Online Certificate Status Protocol (OCSP) statuskontroller i realtid för enskilda certifikat. Det som båda metoderna har gemensamt är att certifikatutfärdaren signerar dem kryptografiskt. Denna signatur säkerställer informationens äkthet och integritet, oavsett om den levereras via HTTP, HTTPS eller till och med ett gammaldags USB-minne.
Om någon försöker manipulera ett CRL- eller OCSP-svar under överföringen, kommer den förlitande partens valideringskontroll att misslyckas och informationen avvisas direkt. Så, vad tillför HTTPS i det här sammanhanget? I de flesta fall inte mycket.
Oväntade risker med HTTPS i PKI
Du kanske undrar varför HTTPS inte är standard, med tanke på dess säkerhetsfördelar. Svaret ligger i ett subtilt men kritiskt problem som beskrivs i RFC 5280, standarden som styr X.509-certifikat och CRL:er. Denna standard avråder från att använda HTTPS för certifikatdistributionspunkter (CDP:er) eller AIA-fält (Authority Information Access). Problemet är något som kallas ett cirkulärt beroende i scenariot, där CRL- eller OCSP-slutpunkten är värd över HTTPS. Den HTTPS-tjänsten är beroende av ett certifikat för att upprätta förtroende. För att validera ett certifikat måste en förlitande part kontrollera dess återkallningsstatus.
Men om återkallningsstatusen finns på samma HTTPS-slutpunkt, fastnar vi i en oändlig loop. RFC 5280 refererar till detta som "obegränsad rekursion", och det är inte bara ett teoretiskt problem; det kan snarare leda till verkliga valideringsfel, bryta förtroendekedjor och störa tjänster.
Vi observerade detta problem med en federal entreprenörskund som stod inför stränga krav från försvarsdepartementet och FedRAMP. Deras säkerhetspolicy krävde användning av HTTPS för alla slutpunkter, inklusive CRL:er och OCSP respondenter. Tyvärr resulterade denna installation i certifikatvalideringsfel under TLS-handskakningar, vilket ledde till kaskadfel över deras brandväggar och tjänster. Och det är så ödesdigert det cirkulära beroendet kan vara. Och specifikt i det här fallet skapades det av de HTTPS-värdade återkallningsslutpunkterna. Genom att omdesigna deras infrastruktur för att hantera signerade CRL:er och OCSP-svar över vanlig HTTP eliminerade vi rekursionsslingan och återställde funktionaliteten utan att kompromissa med säkerhet eller efterlevnad.
I vår PKI-as-a-Service-plattform använder vi en liknande metod och hanterar återkallningsdata via HTTP med inbäddade signaturer och strikta cachkontroller. Detta förenklar validering i molnmiljöer och förhindrar att liknande fel uppstår.
När HTTPS kan vara rätt val
Det finns scenarier där HTTPS kan vara lämpligt för återkallningsslutpunkter, men de kräver noggrann planering och övervägande. Om du till exempel är orolig för integritet, till exempel för att förhindra metadataläckor som avslöjar vilka certifikat som kontrolleras, kan HTTPS kryptera OCSP-frågor och svar. Det är också genomförbart i noggrant kontrollerade miljöer med fästa certifikat, där du kan säkerställa att HTTPS-certifikatets återkallningsstatus valideras via en separat, oberoende sökväg. Ett annat alternativ är att använda out-of-band-validering för att helt undvika cirkulära beroenden. Dessa fall är dock undantaget, inte regeln, och de kräver noggrann arkitektur för att undvika att introducera nya risker.
Ett smartare alternativ är OCSP-häftning
Om du vill undvika live OCSP-sökningar helt och hållet finns det ett bättre alternativ: OCSP-häftningDen här metoden gör det möjligt för servern att hämta och cachelagra ett OCSP-svar och sedan "häfta" det till certifikatet under TLS-handskakningen. Detta eliminerar behovet för klienter att fråga en OCSP-responder direkt, vilket förbättrar prestandan genom att minska externa anrop, stärker integriteten genom att hålla valideringsinformationen på serversidan och ökar motståndskraften ifall OCSP-respondern tillfälligt inte är tillgänglig.
Hur krypteringskonsulttjänster får PKI att fungera för dig
På Encryption Consulting pratar vi inte bara om standarder, vi bygger system som omsätter dem i praktiken. Oavsett om du driftsätter Microsoft ADCS, utnyttja molnbaserade CA:er som AWS Private CA eller Azure Key Vault, använda öppen källkodslösningar som EJBCA, eller anamma våra PKI-som-en-tjänst plattform, säkerställer vi att din infrastruktur för återkallelser är säker och tillförlitlig. Vi designar system som levererar signerade återkallningsdata över HTTP utan att bryta valideringen, implementerar högtillgängliga OCSP- och CRL-svarare och integrerar återkallningskontroller i CI/CD-pipelines och Zero Trust-miljöer. Vår CertSecure-hanterare Plattformen automatiserar hanteringen av certifikatlivscykeln och säkerställer att din verksamhet löper smidigt. Viktigast av allt hjälper vi dig att undvika cirkulära förtroendeloopar genom att noggrant validera alla HTTPS-slutpunkter oberoende.
Slutsats
Inom PKI handlar säkerhet inte bara om kryptering; det handlar om att säkerställa att data är signerade, betrodda och tillgängliga utan att bryta förtroendekedjan. HTTPS har sin plats, men för certifikatåterkallelse gör HTTP ofta jobbet mer tillförlitligt. På Encryption Consulting designar vi PKI system som skapar en balans mellan standarder och verklig prestanda, vilket hjälper dig att undvika fallgropar som kan störa drifttiden eller efterlevnaden.
Redo att bygga en framtidssäker PKI? Kontakta våra PKI-experter på info@encryptionconsulting.com eller besök https://www.encryptionconsulting.com för att upptäcka hur vi kan hjälpa dig.
