포트 443: 보안 웹 트래픽을 위한 HTTPS 포트

일반 HTTP는 네트워크 경로를 관찰할 수 있는 모든 사람에게 요청, 응답, 쿠키 및 양식 데이터를 노출하므로 HTTPS는 웹 세션을 보호하는 표준 방법이 되었습니다. 포트 443은 클라이언트와 서버에 암호화된 대화를 시작할 예측 가능한 장소를 제공합니다. 브라우저에서는 사용자가 포트 번호를 입력할 필요가 없으며 인프라 팀은 잘 알려진 기본값을 중심으로 방화벽, 프록시 및 모니터링 규칙을 작성할 수 있습니다.

번호 자체는 IANA가 관리하는 잘 알려진 포트 레지스트리에서 나옵니다. 초기 보안 웹 트래픽은 SSL을 사용했으며 이후 TLS는 SSL을 최신 보안 프로토콜로 대체했습니다. 애플리케이션 프로토콜이 여전히 HTTP이기 때문에 HTTPS라는 이름이 남아 있지만 TLS로 보호되는 채널 내부에서 전달됩니다. 오늘날 사람들이 SSL 인증서라고 하면 일반적으로 포트 443에서 HTTPS가 사용하는 TLS 인증서를 의미합니다.

포트 80은 HTTP의 기본 포트입니다. 초기 리디렉션, 인증서 자동화 문제, 내부 상태 확인 및 기존 클라이언트와의 호환성에는 여전히 유용할 수 있습니다. 포트 443은 브라우저가 일반 HTTP 트래픽이 시작되기 전에 TLS 핸드셰이크를 예상하기 때문에 다릅니다. 이러한 핸드셰이크를 통해 서버는 인증서를 통해 자신의 신원을 증명하고 개인 데이터가 교환되기 전에 양측이 암호화 키에 동의할 수 있습니다.

최신 프로덕션 사이트에서는 일반적으로 리디렉션이나 인증서 자동화를 위해서만 포트 80을 열어 둡니다. 실제 애플리케이션 트래픽은 443에 도달해야 하며, 종종 HSTS가 활성화되어 브라우저가 HTTPS를 사용해야 한다는 것을 기억하게 됩니다.

인터넷 사용자, 고객 애플리케이션, 웹훅 공급자, CDN, 모바일 앱 또는 파트너 시스템이 HTTPS를 통해 서비스에 연결해야 하는 경우 포트 443을 엽니다. 일반적인 예로는 공개 웹사이트, REST API, GraphQL 엔드포인트, OAuth 콜백, 결제 웹후크, 역방향 프록시 전면 도어, 컨테이너 수신 컨트롤러, 인증으로 보호되는 자체 호스팅 대시보드가 ​​있습니다.

단지 안전해 보인다는 이유로 443을 열지 마십시오. HTTPS는 전송 중인 트래픽을 암호화하지만 취약한 인증, 오래된 소프트웨어, 노출된 관리 경로 또는 위험한 기본 자격 증명을 수정하지는 않습니다. 443을 패치, 로깅 및 액세스 제어가 필요한 공개 진입점으로 취급합니다.

작동하는 HTTPS 엔드포인트를 정렬하려면 4개의 조각이 필요합니다. DNS는 호스트 이름이 올바른 공개 주소를 가리켜야 합니다. 서비스는 443에서 수신 대기해야 합니다. 호스트 방화벽, 클라우드 보안 그룹, 라우터 포트 전달 및 로드 밸런서 수신기와 같은 네트워크 제어는 연결을 허용해야 합니다. 마지막으로 서버는 호스트 이름과 일치하는 인증서를 제시해야 합니다.

두 가지 질문으로 분리됩니다. 포트에 연결할 수 있고 HTTPS가 올바르게 구성되어 있습니까? 포트 검사기는 TCP 경로를 확인합니다. 컬, 브라우저 devtools 및 openssl s_client와 같은 도구는 리디렉션, 인증서, TLS 버전 및 HTTP 응답을 검사하는 데 도움이 됩니다.

Windows Server에서 IIS, Nginx, Caddy 또는 다른 웹 서버를 설치하고 인증서를 사이트에 바인딩하고 Windows Defender 방화벽에서 인바운드 TCP 443을 허용합니다. 클라우드 서버에는 클라우드 보안 그룹이나 방화벽 정책에서 443이 허용되어야 합니다.

Linux에서는 Nginx, Apache 또는 Caddy를 설치하고, 443용 가상 호스트를 구성하고, Let's Encrypt와 같은 공급자의 인증서를 사용하세요. 그런 다음 호스트 방화벽에서 포트를 허용합니다. 예를 들어 Ubuntu에서는 ufw를 사용하여 443/tcp를 허용합니다. 컨테이너에는 호스트 또는 로드 밸런서에 게시된 443도 필요합니다.

macOS에서 포트 443은 대부분 로컬 개발 또는 연구실 환경에 사용됩니다. 여전히 443을 수신하는 프로세스가 필요하며 권한 있는 포트에는 높은 권한이 필요할 수 있습니다.

공용 IP 주소 또는 호스트 이름에 대한 외부 포트 검사부터 시작합니다. 결과가 공개되면 원격 클라이언트는 443에 대한 TCP 연결을 설정할 수 있습니다. 그런 다음 브라우저를 사용하거나 컬 -I https://example.com을 사용하여 HTTP 상태, 리디렉션 및 헤더를 확인합니다.

서버 자체에서 ss -tlnp, netstat 또는 PowerShell을 사용하여 프로세스가 수신 대기 중인지 확인합니다. TLS 세부 정보의 경우 openssl s_client -connect example.com:443 -servername example.com에 인증서 체인 및 핸드셰이크 정보가 표시됩니다.

포트 443이 닫힌 것으로 표시되면 서비스가 실행 중이 아니거나, localhost에서만 수신 대기 중이거나, 잘못된 인터페이스에 바인딩되었을 수 있습니다. 시간이 초과되면 방화벽, 클라우드 보안 그룹, 라우터, ISP 또는 업스트림 공급자가 패킷을 삭제할 수 있습니다. 포트가 열려 있지만 HTTPS가 실패하는 경우 인증서 이름, 인증서 체인, SNI 구성, 역방향 프록시 업스트림 및 애플리케이션 로그를 검사하세요.

클라우드 방화벽을 잊어버리고 호스트 방화벽을 여는 것, 호스트에 게시하지 않고 컨테이너 내부의 Docker 포트 443을 매핑하는 것, CGNAT 뒤의 주거용 네트워크에서 테스트하는 것 등이 자주 발생하는 실수입니다. 이러한 경우 터널, 비즈니스 연결 또는 퍼블릭 클라우드 엔드포인트가 필요할 수 있습니다.

TLS를 단순하고 현대적으로 유지하세요. TLS 1.3 및 TLS 1.2를 선호하고, 더 이상 사용되지 않는 프로토콜을 비활성화하고, 인증서를 자동으로 갱신하고, HTTP를 HTTPS로 리디렉션하고, 인증서 만료를 모니터링합니다. 암호화에만 의존하지 마십시오. 개인 도구 앞에 인증을 두고, 관리 경로를 제한하고, 애플리케이션 스택을 패치하고, 실패한 인증 시도를 기록합니다.

고가치 서비스의 경우 의심스러운 트래픽의 속도를 제한하고 관찰 가능성을 향상시킬 수 있는 역방향 프록시, WAF, CDN 또는 로드 밸런서 뒤에 443을 배치하세요. 서비스가 직원만을 대상으로 하는 경우 광범위하게 접근할 수 있도록 두는 대신 VPN, 신원 인식 프록시, 허용 목록 또는 mTLS를 사용하십시오.