공유기와 IP 카메라 안에 숨어 있는 웹서버
집 공유기 관리 페이지(192.168.0.1 같은 주소)에 들어가 본 적 있으시죠? 그 화면을 띄워주는 것도 웹서버인데요. 보통은 Nginx나 Apache 같은 큰 서버가 아니에요. 메모리 몇 MB 안에서 돌아가도록 만든 아주 작은 임베디드 웹서버인 경우가 많거든요. 그중에서도 가장 널리 쓰이는 오픈소스 프로젝트가 GoAhead예요. Embedthis라는 회사가 관리하고, IP 카메라나 공유기, 프린터, 산업용 제어 장비에 정말 많이 들어가 있어요.
이번에 TLS 핑거프린팅 도구 JA4로 알려진 보안 회사 FoxIO가 GoAhead에서 TLS 관련 버그 세 개를 찾아서 공개했어요. 글 제목에 'Choose your backend'라는 말이 붙어 있는데, 이게 핵심이에요. GoAhead는 TLS를 직접 만들지 않아요. OpenSSL이나 MbedTLS 같은 외부 라이브러리 중 하나를 골라서 빌드하는 구조예요. 그래서 어떤 백엔드를 골랐느냐에 따라 터지는 버그도 달라진다는 거예요.
TLS 백엔드가 뭐냐면
TLS부터 짚고 갈게요. 브라우저 주소창에 뜨는 자물쇠, 그러니까 HTTPS의 'S'를 맡은 암호화 프로토콜이에요. 접속한 서버가 진짜 그 서버인지 인증서로 확인하고, 주고받는 데이터를 암호화해줘요.
TLS를 직접 구현하는 건 보안 업계에서 다들 '절대 하지 말라'고 말리는 일이에요. 그래서 대부분 검증된 라이브러리를 가져다 쓰는데요, 임베디드 쪽은 사정이 좀 복잡해요. 서버급 장비라면 OpenSSL을 쓰면 되지만, 메모리가 빠듯한 기기라면 더 가벼운 MbedTLS를 쓰고 싶어지거든요. 그래서 GoAhead 같은 프로젝트는 가운데에 추상화 계층을 둬요. 일종의 어댑터라고 보면 돼요. '연결 열기, 읽기, 쓰기, 닫기' 같은 공통 인터페이스를 만들어 두고, 그 뒤에 원하는 라이브러리를 꽂아 쓰는 방식이에요.
멀티탭을 떠올리면 쉬워요. 콘센트 모양은 똑같아도 꽂는 기기마다 동작 방식이 다르잖아요. 그래서 이 어댑터 코드는 라이브러리마다 다른 미묘한 차이를 하나도 빠짐없이 맞춰줘야 해요. 문제는 여기서 생겨요.
추상화 계층에서 버그가 생기기 쉬운 지점
세 버그의 정확한 재현 조건과 영향 범위는 원문에 자세히 정리돼 있으니 꼭 확인해 보세요. 여기서는 이런 구조에서 왜 버그가 잘 생기는지를 짚어볼게요.
- 에러 처리 방식이 달라요: OpenSSL은
SSL_ERROR_WANT_READ처럼 '지금은 읽을 데이터가 없으니 나중에 다시 불러줘'라는 신호를 돌려줘요. MbedTLS는 자기만의 에러 코드 체계를 쓰고요. 어댑터가 이 중 하나라도 잘못 해석하면 연결이 멈추거나, 데이터가 잘리거나, 오류를 정상으로 착각할 수 있어요. - 기본값이 달라요: 인증서 검증이 기본으로 켜져 있는 라이브러리도 있고, 따로 설정해야 켜지는 라이브러리도 있어요. 어댑터를 한쪽 기준으로만 짜면 다른 백엔드에서는 검증이 조용히 빠질 수 있어요.
- 버퍼링 동작이 달라요: 라이브러리 안에 이미 복호화된 데이터가 남아 있는데 어댑터는 소켓만 쳐다보고 있으면, 요청 처리가 꼬여버려요.
왜 하필 FoxIO가 찾았을까
FoxIO는 JA3를 만든 John Althouse가 세운 회사예요. TLS 핸드셰이크, 그러니까 연결을 시작할 때 주고받는 인사를 분석해서 클라이언트와 서버를 식별하는 JA4+ 시리즈를 만들었어요. 인터넷에 노출된 서버들의 TLS 응답을 대량으로 들여다보는 게 일인 셈이라, 표준과 다르게 반응하는 구현체를 찾아내기 좋은 위치에 있죠.
GoAhead는 예전에도 보안 이슈가 많았어요. CGI 처리 과정에서 원격 코드 실행이 가능했던 CVE-2017-17562가 대표적이에요. GoAhead 기반 IP 카메라들은 Mirai 같은 IoT 봇넷이 자주 노리는 표적이기도 했고요. 임베디드 기기는 한번 팔리면 펌웨어 업데이트가 잘 안 돼요. 그래서 라이브러리 수준의 버그가 몇 년씩 인터넷에 그대로 노출되는 경우가 흔해요.
업계 맥락: 비슷한 구조는 어디에나 있어요
GoAhead만의 문제는 아니에요. curl도 OpenSSL, wolfSSL, GnuTLS, Schannel, rustls 같은 여러 TLS 백엔드를 지원하는데, curl 보안 권고문을 보면 '특정 백엔드에서만' 생기는 취약점이 꾸준히 나와요. curl 프로젝트가 일부 백엔드 지원을 정리해 온 것도 결국 유지보수 부담 때문이고요.
반대 방향의 흐름도 있어요. Rust 생태계의 rustls처럼 구현체 하나를 메모리 안전한 언어로 제대로 만들자는 접근이에요. 백엔드를 고를 자유는 줄어들지만, 동작이 일관되고 검증해야 할 범위가 분명해져요. 결국 '유연성이냐 일관성이냐'의 트레이드오프예요.
한국 개발자에게 주는 시사점
IoT 기기, 셋톱박스, 산업용 장비 펌웨어를 다루신다면 바로 확인해 볼 만해요.
1. 우리 제품에 GoAhead가 들어 있는지부터 확인하세요. 칩셋 벤더 SDK에 기본으로 들어 있어서 개발팀도 모르는 경우가 꽤 있어요. SBOM(소프트웨어 구성 목록)을 관리하고 있다면 금방 찾을 수 있어요.
2. 어떤 TLS 백엔드로 빌드했는지 확인하고, 그 백엔드가 영향을 받는지 원문과 패치 내역을 대조해 보세요.
3. 백엔드를 바꿀 일이 생기면 기능 테스트에서 끝내지 말고 TLS 동작도 따로 점검하세요. testssl.sh 같은 도구로 인증서 검증, 프로토콜 버전, 비정상 핸드셰이크에 어떻게 반응하는지 보는 습관이 중요해요.
임베디드 개발자가 아니어도 결제 모듈이나 스토리지 SDK처럼 '여러 구현체를 인터페이스 하나로 감싸는' 코드를 짜보셨다면 공감되는 이야기일 거예요.
마무리
추상화는 차이를 가려줄 뿐 없애주지는 않아요. TLS처럼 민감한 영역에서는 그렇게 가려진 차이가 그대로 보안 구멍이 될 수 있다는 걸 이번 GoAhead 사례가 보여줘요.
여러분 프로젝트에도 설정 하나로 백엔드를 갈아끼우는 구조가 있나요? 있다면 백엔드마다 테스트를 얼마나 똑같이 하고 계신지 궁금해요.
🔗 출처: Hacker News