Google로 향하는 트래픽의 99.5%는 이미 암호화되어 있습니다(Google Transparency Report). 방문하는 거의 모든 웹사이트가 HTTPS를 사용합니다. 그런데 프록시 업체들이 설명하지 않는 사실이 있습니다. 「HTTP/HTTPS」로 판매되는 대부분의 프록시는 전체 경로의 절반만 암호화합니다.
암호화 공백이 존재하는 구간
프록시 업체가 자사 제품이 「HTTPS를 지원한다」고 말할 때, 일반적으로 프록시가 HTTPS 웹사이트에 접속할 수 있다는 의미입니다. 웹사이트에서 프록시까지의 연결은 암호화되어 있습니다. 하지만 프록시에서 고객님까지의 연결은 평문 HTTP입니다. 암호화 없는 텍스트 그대로이며, 네트워크상의 누구나 읽을 수 있습니다.
첫 번째 구간에서 어떤 정보가 오가는지 생각해 보십시오. 프록시 로그인 정보와 비밀번호, 요청하는 모든 사이트 주소, 모든 HTTP 헤더가 전송됩니다. 일반 HTTP 프록시에서는 이 정보가 ISP, 네트워크 관리자, 같은 Wi-Fi를 사용하는 사람, 또는 고객님과 프록시 서버 사이의 어떤 장비에서든 완전히 확인 가능합니다.
이것은 이론적인 이야기가 아닙니다. 2023년, 널리 사용되는 Python requests 라이브러리의 취약점(CVE-2023-32681)이 정확히 어떤 일이 벌어지는지 보여주었습니다. 프록시 자격 증명이 포함된 Proxy-Authorization 헤더가 리다이렉트 과정에서 대상 서버로 유출된 것입니다. 근본 원인은 프록시 연결 구간에서 자격 증명이 평문으로 전송되었기 때문입니다. 이 취약점은 패치되기 전까지 2.3.0부터 2.30.x까지의 모든 라이브러리 버전에 영향을 미쳤습니다.
자격 증명 탈취의 규모
Fortinet의 2025 글로벌 위협 환경 보고서에 따르면, 다크넷 포럼에서 유출된 자격 증명이 단 1년 만에 42% 급증하여 1,000억 건 이상의 고유 레코드(이메일, 비밀번호, 세션 토큰, 인증 우회 정보)에 달했습니다. 자격 증명을 실시간으로 수집하는 인포스틸러(infostealer) 악성코드의 활동은 500% 증가한 것으로 나타났습니다.
암호화되지 않은 프록시 연결은 자격 증명이 탈취될 수 있는 또 하나의 취약점입니다. 프록시 비밀번호, 세션 헤더, 접속 중인 사이트 — 연결이 암호화되지 않으면 첫 번째 홉에서 이 모든 정보가 그대로 노출됩니다.
FineProxy의 해결 방법
저희 네트워크의 모든 IP 주소에는 개별 SSL 인증서가 할당되어 있습니다. FineProxy HTTPS 프록시 서버에 접속하면, 고객님의 기기에서 프록시까지의 첫 번째 연결 구간이 SSL/TLS로 암호화됩니다. 자격 증명, 요청 내용, 헤더가 처음부터 보호됩니다.
차이점은 다음과 같습니다:
일반 HTTP 프록시: 고객님의 기기 → 프록시 (평문, 모든 내용 노출) → 웹사이트 (HTTPS, 암호화) FineProxy HTTPS 프록시: 고객님의 기기 → 프록시 (HTTPS, IP별 SSL 인증서로 암호화) → 웹사이트 (HTTPS, 암호화)
전체 통신 체인이 암호화됩니다. 노출되는 구간이 없습니다. 누군가 트래픽을 읽을 수 있는 틈이 없습니다.
저희는 풀 전체에 공유 인증서를 사용하는 것이 아니라, 각 IP마다 전용 SSL 인증서를 발급합니다. 각 프록시는 자체 암호화 ID를 갖춘 독립적인 SSL(보안 암호화) 프록시 서버로 운영됩니다.
IP별 인증서가 중요한 이유
공유 인증서를 사용하면 하나의 설정 실수나 하나의 키 유출이 풀 내 모든 프록시에 영향을 미칩니다. IP별 인증서를 사용하면 각 주소가 암호학적으로 독립됩니다. 하나에 문제가 발생하더라도 나머지는 전혀 영향을 받지 않습니다.
이는 모든 프록시가 독립적인 보안 익명 SSL 프록시로 작동한다는 것을 의미합니다. FineProxy에서 HTTPS 프록시 목록 주소를 구매하시면, 각 주소가 수천 명의 다른 사용자와 인증서 인프라를 공유하지 않고 개별적으로 보안 처리되어 있음을 확인하실 수 있습니다.
TLS 종료 프록시 서버의 역할
이 용어는 기술 문서에서 자주 등장합니다. 쉽게 설명하면, 프록시가 고객님의 암호화된 연결을 수락하고, 요청을 복호화하여 대상 주소를 확인한 뒤, 목적지와 새로운 암호화 연결을 생성하는 방식입니다.
2017년 Georgia Tech 및 University of Michigan 연구진이 수행한 연구에 따르면, 전체 HTTPS 트래픽의 4~10.9%가 특정 형태의 가로채기 프록시를 경유하며, 그중 거의 대부분이 보안을 약화시키는 것으로 나타났습니다. 암호화 등급 하향, 구버전 TLS 사용, 인증서 검증 미비 등이 대표적입니다. 잘못된 프록시 구현은 프록시를 전혀 사용하지 않는 것보다 연결 보안을 더 취약하게 만들 수 있습니다. SSL을 사용하는 것 자체만큼이나 SSL 구현의 품질도 중요합니다.
실제 활용 사례
대규모 스크래핑 — 주요 사이트 대부분이 HTTPS를 요구합니다. 스크래퍼와 프록시 간의 연결도 암호화되어야 하며, 특히 프록시 자격 증명이 포함된 경우에는 더욱 그렇습니다. IP별 SSL을 지원하는 데이터센터 프록시가 이 문제를 깔끔하게 해결합니다.
계정 관리 — 로그인 자격 증명과 세션 토큰은 높은 가치의 공격 대상입니다. 암호화되지 않은 프록시 구간이 있다면 이러한 정보가 네트워크에서 평문으로 전송됩니다. 개별 SSL 인증서를 갖춘 ISP 프록시는 각 계정의 연결을 첫 번째 패킷부터 암호화된 상태로 유지합니다.
API 연동 — Google, Meta, OpenAI, Stripe 등 주요 HTTPS 프로토콜 API는 암호화되지 않은 연결을 거부합니다. 자체 SSL 인증서를 갖춘 전용 프록시를 사용하면 API 키가 노출된 상태로 전송되는 일이 없습니다.
공용 네트워크 — 카페, 호텔, 코워킹 스페이스에서 작업하고 계십니까? HTTP 프록시는 프록시 자격 증명과 브라우징 데이터를 로컬 네트워크에서 평문으로 전송합니다. HTTPS 프록시는 이를 암호화합니다. 공용 Wi-Fi 환경에서 이것은 개인정보 보호와 정보 유출의 차이입니다.
SSL 프록시 주소 구매 시 확인해야 할 사항
세 가지를 확인하십시오. 각 IP에 고유한 인증서가 있는지(공유가 아닌), 프록시 서비스가 HTTPS와 함께 SOCKS5를 지원하는지, 그리고 IP가 제공업체 자체 네트워크 소속인지입니다. FineProxy는 세 가지 모두 충족합니다 — 주소별 개별 SSL, 듀얼 프로토콜 지원, 그리고 저희가 직접 소유하고 관리하는 IP를 제공합니다. 이것이 가장 안전한 프록시 구성을 가능하게 하는 핵심입니다.