Podes compartir unha clave pública de VPN? Comproba estas tres cousas
Publicar a metade pública é como funciona o protocolo; publicar a metade privada é entregar unha identidade. Tres comprobacións deciden que valor tes.
Podes entregar a túa clave pública de VPN a un par, a un provedor ou a un foro, e o túnel segue funcionando. A clave privada non podes entregala, nin sequera ao persoal de soporte, sen entregar a identidade que esa clave demostra. A decisión raramente queda tan limpa, porque a xente confunde que metade do par está a mirar e porque algúns despregamentos tratan o valor público como un nome. Tres comprobacións resólveno: que metade tes, a que a vincula o despregamento e canto custa substituíla.
Comprobación un: que metade do par está no teu portapapeis
As claves asimétricas van en parellas, e a dirección da derivación é todo o asunto. En WireGuard a clave privada son 32 bytes aleatorios e a clave pública calcúlase a partir dela; non podes ir na dirección contraria. wg genkey escribe o valor privado, wg pubkey deriva o público, e só o segundo pertence a unha mensaxe dirixida a un par.
wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt
O mundo dos certificados usa a mesma división con máis pezas móbiles. Un certificado de servidor leva unha clave pública e nomes, e asínao unha clave privada da CA que nunca sae da CA. Un cliente que verifica ese servidor necesita o certificado da CA, que é público, e non ten ningún uso para a clave privada de sinatura da CA.
Se non estás seguro de que valor tes, busca o marcador en lugar do nome do ficheiro. Un bloque PEM que comeza por -----BEGIN PRIVATE KEY-----, ou a forma máis antiga BEGIN RSA PRIVATE KEY, é a metade secreta. Un valor que podes pegar sen ese marcador é candidato a compartirse, suxeito ás dúas comprobacións seguintes.
Comprobación dous: a que vincula o despregamento ese valor público
A seguridade criptográfica e o anonimato son propiedades distintas. A clave pública dun par de WireGuard é un identificador estable dentro do despregamento: a configuración do servidor lístaa, o handshake nómao e un administrador que le rexistros ve a mesma cadea cada vez que ese par se conecta. Publica a clave xunto a unha pregunta sobre a túa instalación e terás vinculado esa cadea con todo o demais da publicación.
Os certificados filtran identidade por deseño. Os campos Subject e subject alternative name son lexibles, e nos certificados TLS de confianza pública o propio certificado publícase nos rexistros Certificate Transparency, que son consultables. Nada diso expón unha clave privada, e todo iso expón unha relación.
Aquí é onde os despregamentos difiren, e iso decide a resposta. Un par de proba refugable nun servidor de laboratorio é un obxecto distinto da clave que identifica o extremo entre sedes dunha empresa, aínda que os bytes parezan idénticos.
Comprobación tres: que podes revogar e con que rapidez
A terceira comprobación separa as dúas metades por completo. Unha clave pública que se publicou pode substituírse segundo o teu calendario. Unha clave privada que se publicou non se pode retirar: borrar a túa copia non toca as copias xa tomadas, e cada par que confiaba nela agora confía en algo que ten un estraño.
A revogación é unha acción de configuración, non unha acción criptográfica. WireGuard non inclúe ningunha lista de revogación, así que quitas o par:
wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart
OpenVPN os despregamentos baseados en certificados revogan o certificado e publican unha CRL que o servidor comproba de verdade mediante crl-verify. Sen esa directiva, a lista de revogación é decoración. En calquera caso a secuencia é a mesma: emite unha substitución, distribúea pola canle admitida e despois retira a identidade antiga.
Os erros que veñen de fundir as tres comprobacións
A maioría das filtracións reais non son unha persoa que decide publicar unha clave privada. Son un perfil enteiro pegado nun foro: un .conf de WireGuard cunha liña PrivateKey, ou un paquete .ovpn cun bloque de clave incrustado, ou unha captura dunha xanela de cliente que inclúe por casualidade o campo da clave. O valor público probablemente estaba ben; viaxou coa parte que non o estaba.
Os fluxos de traballo de soporte son a segunda fonte. Ningún paso de verificación lexítimo necesita a túa clave privada, porque a outra parte deriva da metade pública o que lle cómpre. Cando un formulario ou unha persoa pide o valor privado, a resposta correcta é o público máis a orde local que o produce.
Os rexistros e as capturas de pantalla pertencen á mesma categoría. A saída de diagnóstico pode levar material de claves, identificadores de sesión e enderezos internos, e publicar todo iso para obter resposta a unha pregunta cambia unha pequena comodidade por unha exposición maior.
Cando se filtra un valor privado, retira a identidade
Se un valor privado se escapou, trata esa identidade como retirada. Xera un par novo, instala a metade pública onde os pares a esperan, quita o par antigo ou revoga o certificado antigo e revisa os lugares onde o publicaches. Non podes borrar copias que non controlas, así que a retirada vai do futuro, non do pasado.
Despois escribe a distribución: que clave pertence a que dispositivo, quen ten unha copia, como se entrega unha substitución e quen retira un par retirado. Esas son as partes que a xente esquece, e deciden canto tempo unha filtración segue sendo útil.