현재 많이 쓰이고 있는 방법이
비대칭키 암호화 방법중에 하나를 사용해서 클라가 공개키로 특정 랜덤 데이터를 암호화 해서 서버에 던져주고
서버가 가진 개인키로 제대로 복호화 해서 되돌려 주는지를 검증하는 방법임.
근데 공격자가 중간에 끼어서 중계역할을 하면 이것도 털리기 때문에 실제로는 훨씬 복잡하게 구성됨.
걍 이렇게 해도 되기는 하지만 이런 비대칭키 암호화 방법 말고 천재적인 방법 없을까?
현재 많이 쓰이고 있는 방법이
비대칭키 암호화 방법중에 하나를 사용해서 클라가 공개키로 특정 랜덤 데이터를 암호화 해서 서버에 던져주고
서버가 가진 개인키로 제대로 복호화 해서 되돌려 주는지를 검증하는 방법임.
근데 공격자가 중간에 끼어서 중계역할을 하면 이것도 털리기 때문에 실제로는 훨씬 복잡하게 구성됨.
걍 이렇게 해도 되기는 하지만 이런 비대칭키 암호화 방법 말고 천재적인 방법 없을까?
클라를 검증할 방법은 없어
어차피 클라 바이너리 자체를 해커가 쉽게 얻을텐데
cross domain + https 면 우리가 할일은 다했습니다 능력밖의 일을 고민하지마시져
걍 관리실 가서 키 받아와
비대칭키 써도 프록시 써서 속이면 어차피 뚫림
ㄴ 클라가 진짜 서버말고 중간에 서버인척하는 나쁜서버랑 데이터주고받을수도 있는 경우를 말하는듯
클라는 진짜 서버랑 통신하는 걸로 생각하고 데이터입출력하거 있는데 실제로는 나쁜놈이랑 짝짝꿍하고 있을수있다는 가정인듯 이 경우에 클라는 어떻게 구분을 해야 하느냐!
ㅇㅊㅅ 자회사 다닐때 HSM 장비로 IPSec SSL 다루며 고민좀 해봤지만, ㅇㅇㄹㅈ~
당연히 클라이언트도 서버를 검증해야죠..허참...
왜 ㅇㅊㅅ가 금지어냐 ㅋㅋㅋㅋ 웃김
당연히 클라이언트도 서버를 검증할 필요가 있죠.
이거 왜이럼 댓글에 왠만한 글자 다 금지 되어서 멀 쓸수가 없노.
아놔.
프록시로 속이는걸 방지하기 위해서는 공개키가 올바른지 검증하면 되겠죠?
'아' 밑에 'ㄴ' 넣은 글자 조차 써지질 않음.
삼촌 클라도 서버 검증 해야됨. 클라의 네트워크가 장악당한 상황에서 해커가 가짜 서버 만들고 거기로 연결되게 해서 개인정보라도 입력하도록 유도하면 어쩔거임.
클라가 실행하는 바이너리 자체가 이미 변조된것을 실행하는 것이라면 어쩔 수 없는거고.
공개키에 대응되는 비공개키를 만드는 트릭이 있다면 비대칭키 통신 다 뚫리겠네. 원본 복호화는 불가능하더라도.
프록시로 다 가로채면 되니까
ㅇㅇ가 잘 말해놨네. 댓글 금지어 왜이럼 진짜 뭔 말을 못하겠네.
그래 변조된 클라는 논외지(어쩔수없음) 만약 순정클라가 순정서버말고 해커서버랑 짝짜꿍하면 어떡할거임 예를들어 hts나 mts 으으
ㅇㅇ/공개키에 대응되는 비공개키를 만드는 트릭이 존재 하지 않으니까 비대칭키 암호화를 쓰는거임.
ㅇㅇ
비공개키가 원래의 비공개키가 아니고 대응대는 여러키(원본은 복호화 할수없는)가 존재할 가능성이 있으니까 그걸 찾기만 하면 됩니다.
그럼 클라는 공개키만 보고 의심하지 않고 통신을 시작하겠죠.
그걸 현실적으로 찾기가 불가능 하니까 쓰는거지.
원본비공개키 찾는거보다는 쉽지 않을까 추측해봅니다.