어떤 웹서비스를 분석을 하다가 신기한 것을 발견했다.
크롬 개발자 도구를 통해 로그인 요청을 확인했는데, 요청 바디에 입력한 아이디와 비밀번호가 평문으로 보이지 않았다. 이상한 난수로 보였다.
스스로 추측에도 보안을 위해서 이렇게 했다는 목적은 당연했다. 처음에는 아스키, URL, base64 방식의 인코딩을 통해 서버에서도 간단하게 평문으로 되돌릴 수 있는 행위를 했을 것으로 생각이 들었으며, 왜 이렇게 하는 것일까? 하는 생각과 함께 분석을 더 해보게 되었다.
확인을 해보니 클라이언트단에서 라이브러리를 통하여 AES 암호화를 사용했으며, 암호화에 필요한 key 값은 html 내에 있었다. hidden으로 처리된 input 태그 내에 key 값이 있었으며 이것을 사용하고 있었다.
처음 페이지를 열었을 때 부터 추적을 해보니 중간에 별도로 key를 요청하지 않는 것을 확인하여, 서버에서 처음에 동적으로 html 렌더링을 할 때 key를 생성해주고 잘 담아서 보내주는 것으로 확인했다.
왜 이런 것을 했을까 궁금했다. 어차피 key값을 클라이언트가 가지고 있다면, 복호화도 마음만 먹으면 가능하지 않을까? 또한, 이렇게 하는 것이 정석인지, 특별한 이유가 있는지 궁금하여 검색을 해봤으나 궁금증을 해결할만한 내용을 찾지 못했다.
주변 여러 사람들에게 물어봤다.
여러명에게 물어봐서 궁금증이 해소가 되었으며, 물어보면서 알게된 여러가지 새롭게 알게된 것들이 있었다.
SSL 레이어
처음에는 누군가에게 SSL 레이어를 보라고 답변을 받았다. 결과적으로 질문 내용과는 의미는 없었으나, 덕분에 정확하게 알게되었다.
아마 내 질문이 정확하지 않아 내가 SSL을 통해 암호화가 되어있는 상태를 확인한 것으로 이해를 한 것일까 추측도 되고, 그냥 대충 읽고 SSL 관련이라고 생각하고 답변한 것일수도 있다.
결과적으로 크롬 개발자 도구는 SSL을 통한 암호화 전, 복호화 후의 데이터를 보여주어 실제로 패킷을 직접 확인하지 않는이상 SSL이 동작하여 암호화된 상태를 확인할 수는 없다.
클라이언트와 서버간의 요청 및 응답의 페이로드는 크롬 네트워크 탭과 같이 브라우저 개발자 도구를 사용해서 평문으로 볼 수 있다.
HTTPS가 제공하는 암호화는 통신만 보호하고 페이로드 자체는 보호하지 않는다.
애매하게 알고있었는데, 정확하게 알게되었다.
일반적인 상황에서는 굳이 필요는 없으나, 중요한 데이터라면 중간 탈취 대응을 위하여 양방향 암호화를 사용했을 것이라는 추측
다른 분에게 전송간 암호화를 위하여 그렇게 했을 것으로 생각된다는 답변을 받았다.
나는 순간 어차피 클라이언트가 암복호화에 필요한 key를 알고있다면, 마음만 먹으면 평문으로 되돌릴 수 있어서 의미가 없지 않냐고 물어봤으나, 로그인 요청 탈취 상황에서 key는 어차피 노출이 되지 않기에 상관이 없다고 했다. 그런데 그것 또한 우려된다면, 비대칭키 암호화 방식을 쓰면 되지 않냐고 하여 그 순간 모든 의문들이 해결되었다.
중요한 데이터 전송에는 비대칭키 암호화 방식을 통하여 클라이언트단에서 암호화 하면 안전하다.
결론은 그렇기는 하지만, 일반적인 상황에서는 HTTPS가 제공하는 암호화는 클라이언트와 서버 간의 전체 통신을 보호하기 때문에 요청 body 본문을 암호화를 따로 할 필요는 없다고 한다.
정석이라는 것은 없는 것 같다.
위에 적었던 것도 어떻게든 취약점은 있을 것이고, 그냥 위에 설명했던 방식 정도만이라도, 더 나아가서 완전 허술한 방식으로 평문 전송하지만 않더라도 보안적으로 우수해지는 것은 확실한 것 같다.