인터넷에서 받은 프로그램이 개발자가 배포한 그대로인지, 로그인 요청이 정말 등록된 기기에서 왔는지, 웹사이트가 접속하려던 서버가 맞는지는 어떻게 확인할까요? 내용을 암호화하면 제삼자가 읽지 못하게 숨길 수는 있지만 누가 만들었고 중간에서 바뀌지 않았는지까지 저절로 증명되지는 않습니다. 이때 사용하는 도구가 디지털 서명(digital signature)입니다. 디지털 서명은 종이에 하는 서명처럼 데이터에 신원을 연결하지만 눈으로 필체를 비교하는 대신 개인 키와 공개 키를 사용해 수학적으로 검증하는데요. TLS의 서버 인증, JWS와
결제 서비스가 우리 서버로 다음과 같은 웹훅(webhook)을 보냈다고 해볼까요? HTTPS로 받았으니 무조건 믿고 결제 완료 처리를 해도 될까요? HTTPS는 전송 구간을 보호하지만, 이 요청이 정말 결제 서비스가 만든 것인지 애플리케이션이 확인할 방법은 따로 필요합니다. 공격자가 우리 웹훅 주소를 알아내고 가짜 요청을 직접 보낼 수도 있으니까요. 메시지의 SHA-256 해시를 함께 받으면 해결될 것 같지만, 공격자는 가짜 메시지의 해시도 다시 계산할 수 있습니다. 누구나 계산할 수 있는 해시만으로는 메시지를 만든 상대를 가려낼
대칭키 암호화는 빠르고 단순합니다. 하지만 한 가지 풀기 어려운 문제를 안고 있는데요. "암호화하는 쪽과 복호화하는 쪽이 비밀 키를 어떻게 안전하게 공유할 것인가"입니다. 공격자가 통신을 모두 보고 있는 상태에서 비밀 키를 그대로 보낼 수는 없는데, 그렇다고 매번 사람이 직접 만나서 키를 교환할 수도 없는 노릇이죠. 이 닭과 달걀 같은 문제를 풀기 위해 등장한 것이 비대칭키 암호화입니다. 비대칭키 암호 기술의 주된 목적은 미리 비밀을 공유하지 않은 상대와 안전한 통신을 시작하는 데 있습니다. 이 기술을 디지털 서명에 적용하면 개인
암호화라고 하면 가장 먼저 떠오르는 모습이 자물쇠와 열쇠입니다. 열쇠로 자물쇠를 잠그고, 같은 열쇠로 다시 열고. 이 직관 그대로 동작하는 방식이 바로 대칭키 암호화입니다. 같은 비밀 키 하나로 평문을 암호문으로 바꾸고, 같은 키로 다시 평문으로 되돌리는 약속이죠. 대칭키 암호화의 주된 목적은 같은 비밀 키를 공유하는 사람이나 시스템이 많은 데이터를 빠르게 암호화해 기밀성(confidentiality)을 지키는 데 있습니다. 파일을 저장하거나 HTTPS로 메시지를 주고받을 때처럼, 내용을 제삼자가 읽지 못하게 막아야 하는 자리에 잘
비밀번호를 다루거나, 파일을 다운로드한 뒤 무결성을 검사하거나, JWT 서명을 살펴볼 때 어김없이 등장하는 친구가 있습니다. 바로 암호학적 해시 함수입니다. 해시의 주된 목적은 데이터를 숨겼다가 되찾는 것이 아니라, 짧은 지문을 만들어 같은 데이터인지 또는 중간에 바뀌었는지 확인하는 데 있습니다. 해시 함수는 흔히 "단방향 암호화"라고 불리지만, 암호학에서는 일방향 해시 함수나 일방향성이라고 표현하는 편이 더 정확합니다. 정확히 말하면 해시는 암호화와도 다른 변환인데요. 암호화는 키를 사용해 평문과 암호문을 오갈 수 있지만, 해시는
운영체제 이미지나 개발 도구를 내려받다 보면 파일 옆에 길고 낯선 문자열이 붙어 있는 경우가 있습니다. SHA-256이나 checksum이라는 이름 아래 16진수 숫자가 빼곡하게 적혀 있죠. 내려받기가 끝났으니 파일을 바로 실행해도 될 것 같은데, 왜 굳이 이 값을 함께 제공할까요? 전송 도중 일부가 깨졌거나 저장 장치에서 데이터가 손상돼도 파일명과 용량만으로는 알아채기 어려울 수 있기 때문입니다. 이때 원본과 내려받은 파일이 같은지 확인하는 짧은 값이 체크섬(checksum)입니다. 이번 글에서는 체크섬이 오류를 어떻게 찾아내는지
웹 개발을 하다 보면 브라우저 개발자 도구에서 HTTP 요청 헤더를 뜯어볼 일이 종종 있잖아요? 그때 Host, Origin, Referer... 이 세 녀석이 나란히 있는 걸 보면 "이거 다 비슷한 거 아닌가?" 싶을 때가 있는데요. 헤더 자체가 처음이라면 HTTP 메시지가 어떻게 생겼는지부터 보고 오시면 흐름이 더 잘 잡힙니다. 셋 다 URL이나 도메인 정보를 담고 있으니까 대충 같은 역할처럼 보이거든요. 그런데 막상 CORS 문제를 디버깅하거나 보안 설정을 건드려야 할 때 이 헤더들의 차이를 정확히 모르면 삽질을 피할 수가 없
브라우저에서 자물쇠 아이콘을 누르면 인증서 발급자와 유효 기간, 도메인 이름 같은 정보가 나타납니다. 서버를 운영하다 보면 fullchain.pem, privkey.pem, .crt, .p12처럼 비슷해 보이는 파일도 한꺼번에 마주치고요. 인증서가 만료됐다는 경고는 익숙하지만, 이 파일이 왜 서버의 신원을 증명하는지는 선뜻 설명하기 어렵습니다. 현대의 전송 계층 보안(Transport Layer Security, TLS) 인증서는 단순한 암호화 키도, 사이트가 안전하다는 보증서도 아닙니다. 누구의 공개 키인지, 어느 이름에 사용할
브라우저 주소창에 작은 자물쇠 아이콘이 켜져 있으면 우리는 별다른 의심 없이 정보를 입력합니다. 비밀번호를 치고, 카드 번호를 넣고, 메시지를 보내는데요. 이 자물쇠 한 칸이 사실은 HTTP 위에 한 겹의 보호막을 덧씌운 결과인 셈입니다. HTTPS는 이름에서도 짐작되듯 HTTP에 보안(Secure)을 보탠 형태입니다. 정확히 말하면 HTTP를 TLS라는 암호 통신 위에서 흘려보내는 구조인데요. 이번 글에서는 평문 HTTP가 왜 위험한지, TLS가 그 위에 무엇을 더하는지, 그리고 우리가 평소에 보는 인증서와 자물쇠가 어떻게 신뢰를