[완료] SSL 인증서 배포에 대해서..
글쓴이: mg2000 / 작성시간: 수, 2008/11/12 - 1:51오후
제가 Apache 2.x를 이용해서, 홈페이지를 운영중인데요.
SSL 인증서를 이용하게 되면,
처음에 웹브라우저로 접속시, 인증서를 다운로드 받아서 접속을 하게 되는데요.
이 인증서를 브라우저를 통해서 발급하는 것을 막고,
개별적으로 배포할 수는 없을까요?
허가된 사용자에게만 인증서를 배포하고 싶은데, 어떻게 해야 할까요?
Forums:
질문이 좀
질문이 좀 난해하네요. 인증서 발급을 한다는 것인지? 배포만 한다는 것인지?
SSL 접속시 다운 받는 서버 인증서라면 이건 어짜피 인증서 자체라는 것이
공개용이라 배포 방지라는 것이 필요치 않습니다.
허가된 사용자만 SSL 접속을 하게 한다면 SSL 클라이언트 인증을 사용하면 됩니다.
---------
간디가 말한 우리를 파괴시키는 7가지 요소
첫째, 노동 없는 부(富)/둘째, 양심 없는 쾌락
셋째, 인격 없는 지! 식/넷째, 윤리 없는 비지니스
이익추구를 위해서라면..
다섯째, 인성(人性)없는 과학
여섯째, 희생 없는 종교/일곱째, 신념 없는 정치
---------
간디가 말한 우리를 파괴시키는 7가지 요소
첫째, 노동 없는 부(富)/둘째, 양심 없는 쾌락
셋째, 인격 없는 지! 식/넷째, 윤리 없는 비지니스
이익추구를 위해서라면..
다섯째, 인성(人性)없는 과학
여섯째, 희생 없는 종교/일곱째, 신념 없는 정치
SSL 클라이언트 인증은 어떻게 하는 것인지요?
혹시나 SSL 접속시 다운 받는 인증서를 이용해서, 다른 사람의 패킷도 캡쳐해서 복호화하는 것도 가능하지
않을까 하는 생각도 들어서요. 이런건 불가능한가요?
그래서 허가된 사용자에게만 인증서를 주고 싶은데...
SSL 클라이언트 인증은 어떻게 하는 것인지요?
SSL 클라이언트 인증을 하게 되면, 허가되어 있는지 유무는 어떻게 판단하는지... (IP/MAC주소로??)
인증서를 배포한다는
인증서를 배포한다는 것은 열쇠를 나눠준다는 것인데,
그 열쇠의 복사가 너무도 쉽기 때문에, 사용자에게 오히려 부담을 가중시키게 된다고 생각합니다.
그냥 로그인 인증이 더 나을것 같습니다.
SSL 로 보호하면, 웬만한 방법으로는 알아낼 수 없습니다.
emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/
https://xenosi.de/
인증서와 더부러
인증서와 더부러 공개 키와 비밀 키 쌍으로 자료를 암호화(?) 해서 주고 받는 거라서 다른 사람의 패킷을 가져간다고 해도 쉽게 풀지는 못할 것 같습니다. 제가 SSL에 대해서 이애하고 있는 것이 맞다면 아마도... 관련 정보는 KLDP 위키에도 많이 있던 걸로 기억합니다. 한번 찾아 보시길.
-- 이여송 --
HomePage: http://lys.lecl.net/
Blog: http://lys.lecl.net/blog
LECL: http://www.lecl.net/
E-Mail: yeosong@gmail.com ysnglee2000@lecl.net
MSN: ysnglee2000@hotmail.com
사람천사
서버측에서 자신의
서버측에서 자신의 비밀키를 이용해 자신에 대한 증명서를 만듭니다.
만들어진 증명서를 공인된 제3자에게 넘깁니다.
그 공인된 제3자는 자신의 비밀키를 이용해 증명서에 서명을 해줍니다.
서명된 증명서를 받아 서버에서 인증서로 사용합니다.
접속한 클라이언트는 서버의 인증서를 받습니다.
클라이언트는 세가지 검사를 해서 서버를 인증합니다.
1.서명이 제대로 된 것이 맞나. self-sign 된 것이라면 사용자에게 경고합니다.
2.발급지와 접속지가 일치하는가. 틀리면 경고합니다. 피싱사이트는 이 단계에서 물건너 갑니다.
3.유효기간이 경과하지 않았나. 관리가 부실한 서버는 이 단계에서 물건너 갑니다.
모든 것이 아무 이상 없거나 사용자가 강행돌파를 선택했다면 서버와의 secure sockets layer 를 형성절차를 계속 진행합니다.
만들어진 secure socket layer 를 사용해서 통신을 시작합니다.
SSL 의 형성과정은 SSL 프로토콜 spec. 에 설명되어 있습니다.
초기에 사용하는, public key 를 사용한 비대칭 암호화의 장점은 키의 교환이 필요없다는 겁니다.
아무나 public key 를 사용해서 encrypt 할 수 있지만,
그걸 decrypt 하기 위해선 서버의 private key 가 필요합니다.
중간에서 패킷들을 모두 캡쳐한 뒤 그대로 replay 하는 방식의 공격은
Message Authentication Code 에 의해 차단됩니다.
가능하면 self-sign 하지 말 것이고,
서버의 private key 보호에 총력을 기울인다면,
중간의 누군가가 패킷을 '해독'해서 볼 수 있을 가능성은 0 에 근접합니다.
얼마전 ubuntu 에서 뒤집어지게 난리가 난 적이 있습니다.
전 fedora 유저라 그리 자세히 알아보진 않았지만,
다른 기계들에서 같은 private key 가 만들어지는 사건이었던 걸로 기억합니다.
OTL
클라이언트의 인증서는 PublicKey??
그렇다면 클라이언트의 인증서는 Public Key를 가지고 있고,
클라이언트가 보낼 데이터는 PublicKey로 암호화해서 전송되고,
서버가 PrivateKey를 이용해서 복호화하는 구조라는 것인가요?
반대로 서버가 전송하는 데이터는 클라이언트에서 어떻게 복호화를 하는건지...
서버가 클라이언트로 전송하는 건 대칭키 방식으로 전송된다면,
서버가 전송하는 데이터는 보호받기 어려운것 아닐런지요.
클라이언트가 자신의
클라이언트가 자신의 key 를 서버의 public key 로 encrypt 해서 보내면 될 것 아닙니까.
OTL
아하~ 그러면 되겠군요.
답변 감사드립니다.
그러면 되겠군요~ 가
그러면 되겠군요~ 가 아니라 SSL 2.0이 실제로 그렇게 동작합니다.
SSL 3.0 은 다른 하나가 더 있어서 선택할 수도 있습니다.
검색해보니 ms 사이트가 걸리는 군요. 뭐 참고하기만 할 거니... 한번 읽어보세요.
secret key exchange
어떤 식으로든 대칭형 암호화에 필요한 shared key를 '안전하게' 교환한 후에는
비대칭형 암호화를 더 이상 사용할 필요가 없습니다.
OTL
1. 인증서가
어려운 얘기는 bushi 님이 다 해주셨으니 쉬운 얘기만 하겠습니다.
1.
전통적인 비밀키 암호화 방식을 쓴다면 mg2000님이나 송효진님이 걱정하는 것이 일리 있는 말씀이겠으나...
전자 인증에는 공개키 암호화 방식을 사용하기 때문에...
인증서가 공개적으로 오픈되어있다는 점은 아무런 문제가 되지 않습니다.
공개키 암호화는 통상적인 비밀키 암호화 방식에 비해 모든 면에서 좋은 건 아닙니다.
암호화나 복호화하는 속도도 공개키 암호화 방식이 비밀키 암호화 방식에 비해 느립니다.
키의 길이도 마찬가지입니다. 비밀키 암호화에 쓰는 키의 길이는 128비트 정도면 충분히 안전합니다.
그러나 공개키 암호화에서 같은 정도의 보안 수준을 원한다면 키의 길이가 1024비트 정도는 되어야 합니다.
그런 단점에도 불구하고 공개키 암호화 방식을 전자 인증에 쓰는 건
인증서를 공개적으로 배포해도 안전하다는 장점이 있기 때문입니다.
그러니 허가된 사용자에게만 인증서를 배포하려고 노력하실 필요는 없습니다.
2.
mg2000님이 진정 걱정하셔야 하는 건
mg2000님의 인증서가 널리 뿌려지는 것이 아니라....
악의적인 사람이 자기 인증서를 마치 mg2000님의 인증서인 것처럼 뿌리는 것입니다.
그 인증서를 받는 사람은 mg2000님이랑 통신하는 것으로 착각하고 악의적인 사람한테 정보를 보낼 수 있으니까요.
--
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
질문이 있습니다.. 위에서 아래와 같이
질문이 있습니다..
위에서 아래와 같이 말씀하셨는데요..
---------------------------------------------------------------------------------
접속한 클라이언트는 서버의 인증서를 받습니다.
클라이언트는 세가지 검사를 해서 서버를 인증합니다.
1.서명이 제대로 된 것이 맞나. self-sign 된 것이라면 사용자에게 경고합니다.
2.발급지와 접속지가 일치하는가. 틀리면 경고합니다. 피싱사이트는 이 단계에서 물건너 갑니다.
3.유효기간이 경과하지 않았나. 관리가 부실한 서버는 이 단계에서 물건너 갑니다.
모든 것이 아무 이상 없거나 사용자가 강행돌파를 선택했다면 서버와의 secure sockets layer 를 형성절차를 계속 진행합니다.
만들어진 secure socket layer 를 사용해서 통신을 시작합니다.
---------------------------------------------------------------------------------
클라이언트가 서버로부터 받은 서버 인증서를 검사하기 위해서는 클라이언트 ca가 존재해야하는데 이 클라이언트 ca는 어디에서 받게 되는건가요?
오래된 유물이네요.
루트 인증기관은 소프트웨어와 같이 배포됩니다.
중계 인증기관의 경우, 신뢰된 루트 인증기관을 통해서 배포되기도 합니다.
--
http://www.dgkim.net/
댓글 달기