ERR_SSL_BAD_RECORD_MAC_ALERT: Chrome 해결

문제

Chrome이 페이지를 ERR_SSL_BAD_RECORD_MAC_ALERT로 로드하지 못합니다. 그리고 첫 반응 — 인증서 재발급 — 은 정확히 틀렸습니다. 여기서 거부된 인증서는 없습니다. 이 오류가 뜰 때쯤이면 인증서는 이미 제시·수락됐고, 키가 교환됐고, 연결은 암호화된 상태입니다. 이 오류는 그 암호화된 채널 안에서 발생하며, 한쪽이 인증할 수 없는 암호화된 레코드를 받았다는 뜻입니다.

증상

• Chrome(또는 아무 Chromium 브라우저)이 net::ERR_SSL_BAD_RECORD_MAC_ALERT를 냅니다 — 첫 요청이 아니라 로딩 도중에 뜨는 경우가 많습니다.
• 자주 간헐적입니다 — 새로고침이 될 때도, 안 될 때도 — 그리고 약하거나 붐비는 네트워크와 상관관계가 있습니다.
• Wi-Fi를 이더넷으로 바꾸거나, 네트워크를 바꾸거나, 보안 제품을 끄면 사라집니다.
• 다른 사람은 같은 사이트를 잘 열거나, 같은 기기가 서로 무관한 여러 HTTPS 사이트에서 실패합니다.

이 오류의 진짜 의미

TLS는 데이터를 암호화만 하는 게 아니라 모든 레코드를 인증합니다. 한쪽이 애플리케이션 레코드를 보낼 때 그것을 보호합니다 — TLS 1.2에선 내용에 대해 계산한 MAC을 덧붙이고, TLS 1.3에선 레코드 전체를 태그로 덮는 AEAD 암호로 봉인하죠. 받는 쪽은 복호화해 쓰기 전에 그 보호를 다시 계산하거나 검증합니다. 검사가 실패하면 받는 쪽은 이게 전송 오류인지 의도적 변조인지 알 방법이 없으므로 최악을 가정합니다: 연결을 끊고 치명적 bad_record_mac 알림(TLS 알림 코드 20, RFC 5246 §7.2.2는 TLS 1.2, RFC 8446 §6.2는 TLS 1.3)를 보냅니다. Chrome은 그 알림을 ERR_SSL_BAD_RECORD_MAC_ALERT로 표출합니다.

그러니 번역은 단순합니다: 암호화된 레코드가 손상돼 도착했고, TLS가 그것을 괜찮은 척하기를 거부했다. 이건 기능입니다. 프로토콜은 손상된 바이트를 조용히 앱에 넘기느니 요란하게 실패하도록 설계됐습니다. 진단의 전부는 레코드가 어디서 손상됐는지가 됩니다 — 물리 링크, 스트림을 재암호화하는 미들웨어, 아니면 버그 있는 TLS 종단 장비.

한 가지 중요한 귀결: 이건 인증서·cipher suite·TLS 버전을 바꿔서 고치는 문제가 거의 아닙니다. 그건 핸드셰이크 관심사이고, 핸드셰이크는 이미 성공했습니다. 당신은 이미 수립된 채널의 데이터 무결성을 디버깅하는 중입니다.

가장 흔한 원인 3가지

1. 불안정하거나 잘못 설정된 네트워크 경로가 레코드를 손상 - 전형적 경우. 프레임을 떨구고 재전송하는 약한 Wi-Fi, TLS 레코드를 어색하게 쪼개는 낮거나 안 맞는 MTU의 라우터, 고장 나는 NIC·케이블·드라이버 — 이 중 무엇이든 전송 중 암호화된 레코드 안의 바이트를 바꿀 수 있습니다. TLS는 TCP 체크섬이 놓친 손상을 잡아내고 끊습니다. 그래서 이 오류가 그토록 간헐적이고 네트워크별로 나타나며, 이더넷이나 다른 연결로 옮기면 사라지는 것이죠.
2. TLS 검사 보안 소프트웨어가 재암호화한 스트림을 망가뜨림 - HTTPS 스캔을 하는 백신, 회사 프록시, DLP 장비가 연결을 가로채 복호화·검사하고 브라우저로 재암호화합니다. 그 재암호화에 버그가 있으면 — 레코드 프레이밍 오류, 어긋난 시퀀스 번호, 깨진 cipher 구현 — 브라우저는 MAC/태그가 검증되지 않는 레코드를 받습니다. 지문은 당신 사이트뿐 아니라 한 기기의 여러 HTTPS 사이트에서 발생한다는 점입니다.
3. TLS 오프로드를 하는 로드밸런서·중간 장비의 버그 - 서버측에서 TLS를 종단하는 장비(하드웨어 암호 오프로드, 오래된 LB 펌웨어, 인라인 IPS)가 특정 조건이나 부하 시 레코드를 손상시킬 수 있습니다. 이 경우 실패는 한 사용자를 따라다니기보다 많은/모든 클라이언트에 나타나거나 트래픽 양과 함께 움직입니다.

DechoNet으로 진단하기

• SSL 진단은 네트워크 바깥에서 서버로 전체 TLS 핸드셰이크를 돌리고 레코드 계층을 되읽습니다. 깨끗이 끝나고 유효한 체인을 돌려주면 서버 TLS는 건강하고 손상은 클라이언트 경로에서 일어나는 것이지 오리진이 아닙니다. 그 한 결과가 문제를 절반으로 가릅니다.
• HTTP 진단은 사이트를 아예 네트워크 바깥에서 가져옵니다. 외부 가져오기는 깨끗한데 당신 브라우저만 실패한다면 로컬 링크·프록시·보안 소프트웨어를 정확히 가리킵니다.

해결 체크리스트

• 클라이언트냐 서버냐부터 격리하세요. 외부 TLS 진단을 돌리거나 다른 네트워크(모바일 핫스팟)에서 사이트를 여세요. 외부에선 깨끗한데 당신 네트워크에서 깨지면 문제는 사이트가 아니라 당신의 경로입니다.
• Wi-Fi를 이더넷으로 바꾸거나 다른 네트워크로 옮기세요. 오류가 사라지면 물리 링크·라우터 문제를 확인한 것입니다 — 고장 나는 케이블·NIC를 점검하고, 너무 낮게 잡힌 MTU를 의심하세요(인터페이스 MTU를 낮췄다가 정상화해 보세요).
• TLS 검사 백신이나 회사 프록시를 잠시 끄고 재시도하세요. 그걸로 고쳐지면 가로채기 계층이 레코드를 손상시키는 것입니다 — HTTPS 스캔을 영구히 꺼 두지 말고 업데이트하거나 재설정하세요.
• 모두에게 실패하거나 부하와 함께 커지면 TLS를 종단하는 무엇이든 서버측에서 보세요: 로드밸런서·장비 펌웨어를 업데이트하고, 하드웨어 암호 오프로드를 끈 채로 테스트해 오프로드 버그를 배제하세요.
• 변경할 때마다 SSL 진단을 다시 돌려 레코드 계층이 끝에서 끝까지 깨끗한지 확인하세요.

에스컬레이션 시점

• 외부 SSL 진단은 서버가 건강하다고 하는데 특정 기기 하나가 여러 사이트에서 계속 실패하면, 그 엔드포인트의 보안 소프트웨어를 관리하는 사람에게 올리세요 — 검사 프록시나 백신이 거의 확실한 범인이고, 그 TLS 처리는 그들만 고칠 수 있습니다.
• 실패가 부하와 함께 움직이거나 모든 클라이언트에 나타나면, TLS 종단을 담당하는 쪽(CDN·로드밸런서·장비 벤더)에 레코드 손상 버그로 넘기세요. 인증서와 핸드셰이크가 멀쩡하다는 증거로 외부 핸드셰이크 결과를 함께 주세요.
• 한 기기가 아니라 한 사무실 네트워크에 국한되면 공유 경로 문제입니다 — 네트워크 팀에 넘겨 사이트와 엣지 사이의 중간 장비 체인과 링크 품질을 점검하게 하세요.