참조
http://www.linux-radar.net/reset-password-ubuntu.html


재시작시키고, Esc 키를 눌러 GRUB 메뉴가 나오게 한다. recovery menu를 선택한다.

How to reset your password in Ubuntu How To Reset Your Password In Ubuntu


아래와 같은 Recovery Menu가 나오면, root 메뉴를 선택하고, 셀로 나오게 한다.

 
How to reset your password in Ubuntu 2 How To Reset Your Password In Ubuntu

패스워드를 수정하고 다시 재부팅해서 ubuntu가 정상적으로 뜨게 한다.
passwd '계정명'

Posted by 김용환 '김용환'
TAG ubuntu

댓글을 달아 주세요


역쉬 kaist ~~

http://ftp.kaist.ac.kr/ubuntu-cd/



Index of /ubuntu-cd/

Name Last Modified Size Type
Parent Directory/   -   Directory
.pool/ 2011-Oct-13 19:00:57 -   Directory
.trace/ 2011-Nov-08 16:57:15 -   Directory
10.04/ 2011-Jul-22 01:20:58 -   Directory
10.04.3/ 2011-Jul-22 01:20:58 -   Directory
10.10/ 2011-Mar-30 19:51:32 -   Directory
11.04/ 2011-Oct-13 20:13:29 -   Directory
11.10/ 2011-Oct-13 20:13:21 -   Directory
8.04/ 2011-Mar-30 19:51:32 -   Directory
8.04.4/ 2011-Mar-30 19:51:32 -   Directory
cdicons/ 2009-Apr-09 22:22:42 -   Directory
edubuntu/ 2011-Oct-04 00:30:12 -   Directory
hardy/ 2011-Mar-30 19:51:32 -   Directory
include/ 2011-Jan-24 23:05:48 -   Directory
jigit/ 2011-Jul-22 01:22:49 -   Directory
kubuntu/ 2011-Oct-13 20:49:28 -   Directory
lucid/ 2011-Jul-22 01:20:58 -   Directory
maverick/ 2011-Mar-30 19:51:32 -   Directory
natty/ 2011-Oct-13 20:13:29 -   Directory
oneiric/ 2011-Oct-13 20:13:21 -   Directory
releases/ 2011-Nov-08 16:35:04 -   Directory
.manifest 2011-Oct-13 19:15:46 0.8K text/cache-manifest
.manifest.beta 2011-Sep-23 06:39:32 0.7K text/plain
.manifest.full 2011-Oct-13 19:15:36 3.9K text/plain
FOOTER.html 2006-Feb-02 03:11:06 0.1K text/html
HEADER.html 2011-Oct-04 00:29:57 1.5K text/html
favicon.ico 2011-Jun-16 11:46:13 1.1K image/x-icon
robots.txt 2009-Oct-29 19:22:09 0.1K text/plain

Posted by 김용환 '김용환'

댓글을 달아 주세요


vmware player에서 ubuntu에서 /etc/sudoers의 모드를 잘못 바꾸어서 sudo 명령어를 내릴 때마다. "sudo: /etc/sudoers is mode 0640, should be 0440" 라는 에러가 발생해서 sudo 명령어를 사용할 수 없는 경우가 생겼다.

왠걸 어떻게 해도 sudo를 내릴 수도 없고 원복도 어려웠다.

리스타트 후, shift키를 2-3초 간격으로 눌러주어서 grub이 나오게 한다.  recovery mode를 선택한다.



이후에 'r' 를 눌러 drop to root shell prompt 가 나오게 한다.



root 계정으로 접근했을 텐데, 그 이후에  아래와 같은 명령어를 날려 원복한다.

chmod 0440 /etc/sudoers



그리고, 다시 restart하면 sudo 명령어를 사용할 수 있다.
Posted by 김용환 '김용환'

댓글을 달아 주세요


1. ubuntu 한글 환경 (입력) 구축
http://skcha.tistory.com/196


2. ubuntu 자동 로그인
http://log.bestf.net/230


3. ubuntu Lock Screen 설정 해지 및 시작 설정/ 데스크탑 설정 / 개인 설정

tweak 설치

$ sudo add-apt-repository ppa:tualatrix/ppa
$ sudo apt-get update
$ sudo apt-get install ubuntu-tweak



좌측메뉴에서 security related 를 선택하고,  disable "Lock Screen"하니, timeout되면서 screen lock되는게 사라진다.



4. root 패스워드 변경
sudo 쓰기 귀찮음.
http://knight76.tistory.com/entry/Ubuntu-11-root-password패스워드-변경

5. ssh 서버 및 클라이언트 쓰기
윈도우에서 작업하기 편하게 함

sudo apt-get install openssh-server openssh-client



Posted by 김용환 '김용환'
TAG ubuntu

댓글을 달아 주세요



 

jdbc driver 명

mysql의 connectTimout,

socketTimeout 에 해당되는 값

기본값

단위

적용방법

Oracle Thin Driver

* connectTimout :  oracle.net.CONNECT_TIMEOUT

* socketTimout :  oracle.jdbc.ReadTimeout

0

(무한대기)               

밀리세컨드(ms) 

driver단에서 사용불가하고, dbcp 설정에서 사용

<property name="connectionProperties"
value="
oracle.net.CONNECT_TIMEOUT=6000;

oracle.jdbc.ReadTimeout=6000"/>

MS-SQL Server

(jTDS Driver)

* connectTimout :  

loginTimeout

* socketTimout :  

socketTimeout

0

(무한대기)  

초 (second)

 

driver단에서 사용가능

jdbc:jtds:sqlserver://server:port/database;

loginTimeout=60;

socketTimeout=60

MYSQL Driver

* connectTimout :  

connectTimeout

* socketTimout : 

socketTimeout

0

(무한대기) 

밀리세컨드(ms) 

사용 가능

jdbc:mysql://xxx.xx.xxx.xxx:3306/database?
 
connectTimeout=60000&

socketTimeout=60000

Cubrid

Thin Driver

조정 불가능

5

 

 

 

만약 우리가 관리하고 있는 서버에서 설정을 하지 않았다면 계속 무한대기 상태로 있을까요?

OS 레벨에서는 tcp 레벨 단위의 socket timeout 이 있는데요.  이 값에 영향을 받습니다.

리눅스의 경우는 커널 파라미터라고 그 값을 볼수도 바꿀 수 있습니다.

 

tcp_keepalive_time 파라미터는 " keepalive 가 활성되 되어 있을 경우, 얼마나 자주 TCP 가 keepalive 메세지를 보내게 할 것인지를 설정."에 대한 값을 정의합니다.  tcp_fin_timeout은 "tcp fin 패킷에 대한 timeout"이며, tcp_syn_retries 는 "tcp syn 패킷을 몇번이나 시도할 것이냐"에 대한 값입니다. 이 모든 값은 os level 단의 timeout에 큰 영향을 미칩니다.

 

자세히 보도록 하겠습니다.

ubuntu 설정으로는 7200초 (2시간)이 디폴트값입니다.

cat /proc/sys/net/ipv4/tcp_keepalive_time
7200


/proc/sys/net/ipv4/tcp_keepalive_intvl/와 /proc/sys/net/ipv4/tcp_keepalive_probes 의 값과 함께 계산되어 timeout이 될 때, 상당히 긴 시간동안 timeout 이벤트가 일어나지 않을 가능성이 높으니, db에 대한 timeout은 반드시 지정될 필요가 있습니다.

 

tcp fin 패킷을 못받는 경우에 대한 timeout은 60초 (1분)입니다.

cat /proc/sys/net/ipv4/tcp_fin_timeout
60

 

tcp syn 패킷에 대한 시도는 5번이나 합니다.  

cat /proc/sys/net/ipv4/tcp_syn_retries

5

실제 timeout 은 특정 이벤트마다 시도 값 * timeout + 약간의 delay  으로 계산이 되겠죠?

 

 

DB단에서 이런 리눅스의 tcp 커널 파라미터를 수정하여 성능을 높이는 일을 많이하고 있습니다만, 웹 서비스쪽은 굳이 할 필요는 없다고 생각듭니다. 어플단에서 충분히 할 수 있으니까요.

os level 단에 있는 timeout을 의존하기 보다는 db connection에 대해서 socket timeout , connect timeout을 잘 정의하는 것이 훨씬 운영면에서 편리합니다. 

Posted by 김용환 '김용환'

댓글을 달아 주세요


점점 까먹어진다. 틈틈히 복습하자..



1. select function 좋은 예제


5초동안 표준입력으로부터 입력값을 받는다. 5초 이내로 글자를 받으면 (해당 fd에 대한 값이 변경) 입력받은 문자를 그대로 출력

 

소스
#include <stdio.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>

#define TIMEOUT 5
#define BUF_LEN 1024

int main(void) {

 struct timeval tv;
 fd_set readfds;
 int ret;

 FD_ZERO(&readfds);
 FD_SET(STDIN_FILENO, &readfds);

 tv.tv_sec = TIMEOUT;
 tv.tv_usec = 0;

 //  nfds is the highest-numbered file descriptor in any of the three sets, plus 1.

 ret = select (STDIN_FILENO + 1, &readfds, NULL, NULL, &tv);
 if (ret == -1) {
  perror("select");
  return 1;
 } else if (!ret) {
  printf ("%d senconds elapsed. \n", TIMEOUT);
  return 0;
 }

 if (FD_ISSET(STDIN_FILENO, &readfds)) {
  char buf[BUF_LEN + 1];
  int len;

  len = read(STDIN_FILENO, buf, BUF_LEN);
  if (len == -1) {
   perror("read");
   return 1;
  }

  if (len) {
   buf[len] = '\0';
   printf("read : %s \n", buf);
  }

  return 0;
 } 

 fprintf(stderr, "This should not happen!\n");
 return 1;

}

 

$ gcc select-demo.c
$ ./a.out
5 senconds elapsed.
$ ./a.out
123
read : 123
 


2. man select 내용

       /* According to POSIX.1-2001 */
       #include <sys/select.h>

       /* According to earlier standards */
       #include <sys/time.h>
       #include <sys/types.h>
       #include <unistd.h>

       int select(int nfds, fd_set *readfds, fd_set *writefds,
                  fd_set *exceptfds, struct timeval *timeout);

       void FD_CLR(int fd, fd_set *set);
       int  FD_ISSET(int fd, fd_set *set);
       void FD_SET(int fd, fd_set *set);
       void FD_ZERO(fd_set *set);


       #include <sys/select.h>

       int pselect(int nfds, fd_set *readfds, fd_set *writefds,
                   fd_set *exceptfds, const struct timespec *timeout,
                   const sigset_t *sigmask);

 

pselect 라는 것이 있는데. 차이점이 있다.
1. 시간과 관련된 struct이 다르다. select : timeval, pselect : timespec (초와 나노초)
2. 시그널 관련 sigset_t가 있다. 시그널과 관련된 mask를 파라미터로 사용한다. select 함수는 signal 파라미터를 사용하지 않는다.
   (pselect를 사용하는 예제를 거의 못본 것 같다. 나는 아직까지는 select만 사용하는 어플만 본 것 같다.)


pselect 예제는 sigprocmask 함수를 사용한 예제와 비슷하다.
 ready = pselect(nfds, &readfds, &writefds, &exceptfds,
                           timeout, &sigmask);


           sigset_t origmask;
           sigprocmask(SIG_SETMASK, &sigmask, &origmask);
           ready = select(nfds, &readfds, &writefds, &exceptfds, timeout);
           sigprocmask(SIG_SETMASK, &origmask, NULL);

 


3. poll 좋은 예제

#include <stdio.h>
#include <unistd.h>
#include <sys/poll.h>

#define TIMEOUT 5

int main(void) {
 struct pollfd fds[2];
 int ret;

 fds[0].fd = STDIN_FILENO;
 fds[0].events = POLLIN;
 
 fds[1].fd = STDOUT_FILENO;
 fds[1].events = POLLOUT;

 ret = poll(fds, 2, TIMEOUT * 1000);
 if (ret == -1) {
  perror("poll");
  return -1;
 }
 
 if (!ret) {
  printf("%d seconds elapsed. \n", TIMEOUT);
  return 0;
 }

 if (fds[0].revents & POLLIN) {
  printf ("stdin is readable.\n");
 }

 if (fds[1].revents & POLLOUT) {
  printf ("stdout is writable.\n");
 }

 return 0;
}

 

결과
$ gcc poll-demo.c
$ ./a.out
stdout is writable.

$ touch xx.txt
$ ./a.out  < xx.txt
stdin is readable.
stdout is writable.


4. man poll

       #include <poll.h>

       int poll(struct pollfd *fds, nfds_t nfds, int timeout);

       #define _GNU_SOURCE
       #include <poll.h>

       int ppoll(struct pollfd *fds, nfds_t nfds,
               const struct timespec *timeout, const sigset_t *sigmask);


         struct pollfd {
               int   fd;         /* file descriptor */
               short events;     /* requested events */
               short revents;    /* returned events */
           };

 

5. select 와 poll 비교

- poll 은 가장 높은 fd에 +1을 할 필요가 없다.
- poll은 fd가 클 경우 좋다. select는 모든 fd의 비트를 검사한다. (select는 for loop에서 set 된 정보를 찾음)
  -> 그렇다고 select가 안좋다고 말할 수 없다. 이벤트가 자주발생하고 연속적인 시스템에서는 select를 사용 (apache http)
     poll은 어느 정도 분산되어 있거나 크기 제한이 없는 여러개의 array 형태로 넘겨서 사용할 때 유용하다.
            그리고, 필요한 것만 비교할 경우가 효과적이다.
- select는 fd set을 초기화를 해야 하지만, poll은 입력과 결과를 분리할 수 있다.
- select는 사이즈 제한이 있다.
- select가 이식성이 좋음. 어떤 시스템은 poll을 쓰지 않기도 함
- select의 timeout이 poll의 timeout보다 안정적임

 


6. 레벨트리거와 엣지트리거

select와 poll 은 레벨트리거

레벨 트리거  : 파일에 데이터가 있는지 여부에 대한 판단, 완전히 다 읽을때까지 계속 이벤트를 발생한다. 즉 '동안'에 집중
에지 트러거  : 파일이 특정 데이터를 저장하는 '특정시점'에만 발생

좋은 설명은 다음 블로그에서 잘 해놨다.
http://no1rogue.blog.me/30091246644
- 에지 트리거 : 인터럽트가 발생하여 레벨이 상승하거나 하강할 때.
- 레벨 트리거 : 인터럽트가 발생하여 그 레벨이 인가될 때.

 

 


출처
- http://no1rogue.blog.me/30091246644
- 리눅스 시스템 프로그래밍, 한빛미디어
- http://kldp.org/node/35279

Posted by 김용환 '김용환'

댓글을 달아 주세요


과거에 https 연결해서 테스트한 적이 있었고, 그 이후에 쓰지 않다가 최근에 https로 사용해야 해서 https로 테스트하던 중에 발견되었습니다.

브라우져상의 에러

(크롬) : err_connection_reset 에러 발생


IE 쪽



Apache Http 서버의 설정파일이나 java 연결부분, 인증서 부분에도 특별한 문제점을 파악하지 못했습니다.

에러 로그에서도 특별한 징후를 찾을 수 없었습니다.

 

그래서 터미널에서 해당 서버에 로그인 한 후, openssl을 이용해서 디버깅을 해보았습니다.

localhost의 443포트에 접속해서 ssl 통신을 체크하였습니다.


#  openssl s_client -host localhost -port 443 -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
write:errno=104


 

ssl 통신은 최초 통신의 시작을 hello 라는 패킷을 client와 server 에 서로 전달하는데. 그 부분에서 에러가 발생한 것입니다. 저는 좀 더 상세한 정보를 보기 위해서 linux의 시스템 콜과 에러 내용에 대해서 정확히 분석하기 위해서 strace 라는 리눅스 명령어를 이용했습니다.

# strace openssl s_client -host localhost -port 443 -state
gettimeofday({1318989368, 765821}, NULL) = 0
poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])
send(4, "\204\27\1\0\0\1\0\0\0\0\0\0\20_kerberos-master\4_u"..., 49, MSG_NOSIGNAL) = 49
poll([{fd=4, events=POLLIN}], 1, 1000)  = 1 ([{fd=4, revents=POLLIN}])
recvfrom(4, "\204\27\205\203\0\1\0\0\0\1\0\0\20_kerberos-master\4_u"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.22.64.6")}, [16]) = 100
close(4)                                = 0
write(3, "\200t\1\3\1\0K\0\0\0 \0\0009\0\0008\0\0005\0\0\26\0\0\23\0\0\n\7\0\300"..., 118) = 118
write(2, "SSL_connect:SSLv2/v3 write clien"..., 42SSL_connect:SSLv2/v3 write client hello A
) = 42
read(3, 0x89bc4d0, 7)                   = -1 ECONNRESET (Connection reset by peer)
write(2, "SSL_connect:error in SSLv2/v3 re"..., 50SSL_connect:error in SSLv2/v3 read server hello A
) = 50
write(2, "write:errno=104\n", 16write:errno=104
)       = 16
shutdown(3, 0 /* receive */)            = -1 ENOTCONN (Transport endpoint is not connected)
close(3)                                = 0
exit_group(0)                           = ?




 

서버에서 접속을 끊었다는 ECONNRESET (error number 104) 이라는 에러가 발생되었음을 정확히 확인할 수 있었습니다.

 

ECONRESET 은  TCP 통신과 연관이 있습니다

 

fig1o.png

 

 

A,B 노드가 있다고 가정하고, A가 Syn 패킷을 통해 connection을 시도했지만, 서버에서 port가 존재하지 않거나 중간에 소켓에 문제가 생겨 서버로부터 RST 패킷을 받게 됩니다. 이 때, -1이 리턴되고 ECONNRESET이 errono로 셋팅되며, Connection reset by peer 메시지를 보여 줍니다.


 


일반적인 케이스는 아파치 에러 로그(LogLevel debug 설정)에 보여지기도 하지만, 이번 경우는 에러 로그에 남지 않았습니다. 그 이유는 Http 단 연결이 아닌 TCP 단에서의 연결에서 종료되었기 때문입니다.

 

만약 정상적인 연결이었다면, 아래와 같이 SSL 통신하고 클라이언트에서 인증서를 받는 형태로 가게 됩니다.


 

# openssl s_client -host localhost -port 443 -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=1 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
verify error:num=20:unable to get local issuer certificate
verify return:0
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
---
Certificate chain
 0 s:/C=KR/ST=adsfsdf/L=dddad/O=NHN/OU=GAT/OU=Terms of use at www.crosscert.com/rpa (c) 04/OU=Authenticated by KECA, Inc./OU=Member, VeriSign Trust Network/CN=google.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
---
Server certificate
Server certificate
-----BEGIN CERTIFICATE-----
MIIFgDCCBGigAwIBAgIQFZkr7WyBWj+WqYaiWeajwzANBgkqhkiG9w0BAQUFADCB
tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEvMC0GA1UEAxMm
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzMwHhcNMTAxMjA2
MDAwMDAwWhcNMTIxMjA1MjM1OTU5WjCB7zELMAkGA1UEBhMCS1IxEDAOBgNVBAgT
B0t5dW5nZ2kxFDASBgNVBAcUC0p1bmdqYS1kb25nMQwwCgYDVQQKFANOSE4xDDAK
BgNVBAsUA0dBVDE1MDMGA1UECxMsVGVybXMgb2YgdXNlIGF0IHd3dy5jcm9zc2Nl
cnQuY29tL3JwYSAoYykgMDQxJDAiBgNVBAsTG0F1dGhlbnRpY2F0ZWQgYnkgS0VD
QSwgSW5jLjEnMCUGA1UECxMeTWVtYmVyLCBWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MRYwFAYDVQQDFA15YTkubmF2ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQDf6nldrBCfR7cgGBA7PcVkGT7xvF7X/KadRBzWtFYnba2rxd/dpQ4k5UkM
4wLr2xK6clCS1xodZp9mhLI0ig79qY6IloAghkJEmjz13Ui1c0o0ZincqbUsa7Rp
+VYSesEguUYdmj5FwWmtMC6do6TrRGjp1ExThvMEEiqMhi48FwIDAQABo4IB0jCC
Ac4wCQYDVR0TBAIwADALBgNVHQ8EBAMCBaAwRQYDVR0fBD4wPDA6oDigNoY0aHR0
cDovL1NWUlNlY3VyZS1HMy1jcmwudmVyaXNpZ24uY29tL1NWUlNlY3VyZUczLmNy
bDBFBgNVHSAEPjA8MDoGC2CGSAGG+EUBBxcDMCswKQYIKwYBBQUHAgEWHWh0dHBz
Oi8vd3d3LmNyb3NzY2VydC5jb20vcnBhMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr
BgEFBQcDAjAfBgNVHSMEGDAWgBQNRFwWU0TBgn4dIKsl9AFj2L55pTB2BggrBgEF
BQcBAQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTBA
BggrBgEFBQcwAoY0aHR0cDovL1NWUlNlY3VyZS1HMy1haWEudmVyaXNpZ24uY29t
L1NWUlNlY3VyZUczLmNlcjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFn
ZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRw
Oi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwDQYJKoZIhvcNAQEFBQAD
ggEBAFkByKz9YKlUV59kvdxMwwpvOLc4SNu4Q9mh1QKzQCyZ4oJoZ2FjNxJKU9rq
6YwkC5DrSZ5KZYzSt1CyoksVuWKNkU8E9Tr+np3Hl9inq8OBtUmMTujwtBW7DOK5
3VQfZIa9L4ftuLBBBrkchaIJAO+Wt6QOaxj8nPCdtFz6jE5+y0Tcegnh/37lgTvJ
A0FO+Q9flceQfXOhML/FSfqFTfTDZaXZsrNabSaZqmdbX28TTbsj8wPx71IsxdBs
yKbTF1oz5ywx9xNN6QYhCu0SyQQbxr62e0Oo3o5XFP/ljyjmzIoneWheo5UgsKvI
wDT/ZiM6lixt0CWxSHFNfm9m4yM=
-----END CERTIFICATE-----
subject=/C=KR/ST=Kyunggi/L=Jungja-dong/O=NHN/OU=GAT/OU=Terms of use at www.crosscert.com/rpa (c) 04/OU=Authenticated by KECA, Inc./OU=Member, VeriSign Trust Network/CN=google.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 3499 bytes and written 316 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 8F2B9AB40A4AD05C46DE0F4F04D80355308840534ADAFE4C68FF3389B46981EB
    Session-ID-ctx:
    Master-Key: 5610D7F76F9BD9EE4896F5C9599323CBCA58111579FDECA32BDF05E570D159C65F395B030442E4BC432109B71A238DA5
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1318991229
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---






ssl 통신(handshaking) 은 다음과 같습니다.

1. Client(터미널에서 openssl 요청, 브라우져)가 Https를 이용해서 Server(google.com) URL로 통신을 시도한다. Hello 라는 통신인데, 지원 가능한 암호방식, 키 교환 방법, 압축 방식을 서로 의사소통합니다.

2. Server(google.com)가 인증서를 client에 전달합니다.

3. Client에서는 Server 인증서 public key 얻어옵니다. (기본적인 인증서에 대한 검증 절차를 거침. 인증서의 도메인과 실제 요청하는 도메인이 갖은지. CA가 정확하게 인증했는지 등등)

5. Client에서는 public key를 이용한 pre-master key(RSA 키교환) 를 생성하고 서버에 전달하여 상호간의 키를 교환하도록 합니다..  (key exchange)

6. Client에서 인증서 검증 정보를 보내고,  SSL 통신에 의해 결정된 암호방식, 키교환 방법, 서명방식, 압축방식을 다음부터 적용할 것을 정합니다. (cipher spec)

6. Server는 Client로부터 받은 pre-master key(또는 pre master secret)를 private key로 디코딩하고 Session ticket으로 생성하고 Client에 전송합니다.  (session ticket)

7. Server 에서는 Session Ticket를 이용하여 Server와 Client간의 발생하는 모든 통신은 암호화가 되게 합니다




통신 에러는 client->server 로 SSL Handshake 하는 첫번째 단계("1. Client(터미널에서 openssl 요청, 브라우져)가 Https를 이용해서 Server(google.com) URL로 통신을 시도한다. Hello 라는 통신인데, 지원 가능한 암호방식, 키 교환 방법, 압축 방식을 서로 의사소통합니다. ")에서 문제가 발생한 것이었습니다.

 

이에 대한 정확한 진단을 위해서 아파치 서버의 설정 파일을 수정하였습니다.

 

Prefork 설정에서 StartServer와 MaxClient를 1로 주어 리스타트를 하였습니다.

 

# vi /usr/local/apache/conf/httpd.conf
StartServer 1
MaxClient 1


# /usr/local/apache/bin/httpd -k restart
[프로세스 재시작]


# ps -ef | grep httpd
1111 root /usr/local/apache/bin/httpd
1112 www  /usr/local/apache/bin/httpd

 


 

root 권한으로 동작하는 httpd 데몬과 www 권한으로 동작하는 httpd 데몬(worker)만이 리눅스에서 실행하게 됩니다.

Http 요청이 웹서버에 들어오면 1111 root 권한으로 실행되는 httpd 데몬이 1112 라는 httpd로 요청을 전달시킵니다.

그래서, www 권한으로 동작하는 httpd 데몬에다가 시스템 콜을 확인하는 strace를 붙여서 프로세스가 어떤 일을 하는지 확인합니다.

 

strace 로 프로세스를 띄우고, openssl로 https 패킷을 날리면 다음의 결과를 얻게 됩니다.

 

# strace -p 1112
 
....
gettimeofday({1318989190, 741852}, NULL) = 0
writev(12, [{"HTTP/1.1 200 OK\r\nDate: Wed, 19 O"..., 289}, {"Total Accesses: 1\nTotal kBytes: "..., 396}], 2) = 685
gettimeofday({1318989190, 742236}, NULL) = 0
gettimeofday({1318989190, 742348}, NULL) = 0
write(15, "127.0.0.1 - - [19/Oct/2011:10:53"..., 128) = 128
gettimeofday({1318989190, 742594}, NULL) = 0
gettimeofday({1318989190, 742693}, NULL) = 0
times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = -2134126829
gettimeofday({1318989190, 742955}, NULL) = 0
shutdown(12, 1 /* send */)              = 0
poll([{fd=12, events=POLLIN}], 1, 2000) = 1 ([{fd=12, revents=POLLIN|POLLHUP}])
read(12, "", 512)                       = 0
close(12)                               = 0
read(6, 0xbfbe39c7, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1318989190, 743670}, NULL) = 0
semop(21954565, 0x5a9898, 1)            = 0
epoll_wait(8, {}, 2, 10000)             = 0
epoll_wait(8, {}, 2, 10000)             = 0
epoll_wait(8, {}, 2, 10000)             = 0
epoll_wait(8, {}, 2, 10000)             = 0
epoll_wait(8, {}, 2, 10000)             = 0
epoll_wait(8, {}, 2, 10000)             = 0
epoll_wait(8, {{EPOLLIN, {u32=137901384, u64=137901384}}}, 2, 10000) = 1
accept(5, {sa_family=AF_INET, sin_port=htons(51035), sin_addr=inet_addr("127.0.0.1")}, [16]) = 12
fcntl64(12, F_GETFD)                    = 0
fcntl64(12, F_SETFD, FD_CLOEXEC)        = 0
semop(21954565, 0x5a98a4, 1)            = 0
gettimeofday({1318989258, 992134}, NULL) = 0
getsockname(12, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
time(NULL)                              = 1318989258
fcntl64(12, F_GETFL)                    = 0x2 (flags O_RDWR)
fcntl64(12, F_SETFL, O_RDWR|O_NONBLOCK) = 0
gettimeofday({1318989258, 993069}, NULL) = 0
time(NULL)                              = 1318989258
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
chdir("/home/www/apps/httpd-2.2.21")    = 0
rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_INTERRUPT}, {SIG_DFL, [], SA_RESETHAND}, 8) = 0
kill(1112, SIGSEGV)                     = 0
sigreturn()                             = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 1112 detached




 

httpd 데몬에서 중간에 read 콜 이후에 Resource temporarily unavailable 이 일어나고.
나중에는 SIGSEGV (Segmentation fault)가 발생하게 되었습니다. 마지막에는 www 프로세스가 종료되었음을 확인할 수 있었습니다. (kill(1112, SIGSEGV))


즉, 요청이 들어올 때마다 www 프로세스(apache worker)가 동작하다가 Segment fault가 발생한 것이었습니다.
그리고, ps 명령어를 이용해서 프로세스 확인을 하니. 새로운 프로세스가 떠져 있는 것을 확인했습니다.

 

# ps -ef | grep httpd
1111 root /usr/local/apache/bin/httpd
1114 www  /usr/local/apache/bin/httpd

 


 

아파치에 문제가 있는 것은 확인했습니다. 그 중의 어디서 문제가 있는지 확인을 해야 했습니다.

 

vhost.conf 설정 파일은 이런식으로 되어 있습니다.

먼저 회사에서 만든 특정 모듈을 읽고, mod_ssl을 읽는 구조로 되어 있습니다.

 


NameVirtualHost *:80
NameVirtualHost *:443
 
LoadModule session_auth_module modules/mod_auth.so
<IfModule mod_auth.c>
....
 </IfModule>
 
#SSL Module
LoadModule ssl_module modules/mod_ssl.so
 
<IfModule mod_ssl.c>
    SSLRandomSeed startup builtin
    SSLRandomSeed connect builtin
    Listen 443
    AddType application/x-x509-ca-cert .crt
    AddType application/x-pkcs7-crl    .crl
    SSLPassPhraseDialog  exec:conf/sslcert.pass
    SSLSessionCache         dbm:/usr/local/apache/logs/ssl_scache
    SSLSessionCacheTimeout  300
    SSLMutex  file:/usr/local/apache/logs/ssl_mutex
</IfModule>

<VirtualHost *:80>
..
</VirtualHost>
 
<VirtualHost *:443>
..
</VirtualHost>




좀 더 자세히 문제를 확인하기 위해서 httpd 데몬에 대해서 디버깅(gdb)를 하였습니다.


# gdb httpd
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
(gdb)  b ap_process_request
Breakpoint 1 at 0x80923f9: file http_request.c, line 276.
(gdb)
Note: breakpoint 1 also set at pc 0x80923f9.
Breakpoint 2 at 0x80923f9: file http_request.c, line 276.
(gdb) run -X -d /usr/local/apache
Starting program: /home/www/apps/httpd-2.2.21/bin/httpd -X -d /usr/local/apache
[Thread debugging using libthread_db enabled]
[New Thread 0xb7f85700 (LWP 8718)]
Detaching after fork from child process 8721.
Detaching after fork from child process 8722.
Detaching after fork from child process 8723.
Detaching after fork from child process 8724.
Detaching after fork from child process 8725.
Detaching after fork from child process 8726.
Detaching after fork from child process 8727.
Detaching after fork from child process 8728.
Detaching after fork from child process 8729.
Detaching after fork from child process 8730.
Detaching after fork from child process 8731.
Detaching after fork from child process 8732.
Detaching after fork from child process 8733.
Detaching after fork from child process 8734.
Detaching after fork from child process 8735.
(요청 날림, openssl s_client....)
Program received signal SIGSEGV, Segmentation fault.
0x003a91bd in ssl23_accept () from /lib/libssl.so.6
(gdb) bt
#0  0x001451bd in ssl23_accept () from /lib/libssl.so.6
#1  0x010c9341 in SSL_accept () from /usr/local/apache/modules/mod_auth-test.so
#2  0x00000000 in ?? ()
(gdb) n
Single stepping until exit from function ssl23_accept,
which has no line number information.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists
.



회사에서 만든 특정 모듈의 SSL_accept 메소드에서 문제가 되었음을 확인할 수 있었습니다.

 

담당자분께 확인하니 auth모듈에서는 자체적인 ssl 인증 모듈을 static linking해서 가지고 있다고 합니다.

즉, mod_ssl을 쓰지 않고 auth 모듈을 사용하는 웹 서버를 위해서 만들어 진 것인데요. 이 부분이 저희가 사용하고 있는 mod_ssl의 ssl 버전과 충돌이 난 것입니다. 그래서 segmentation fault가 난 것입니다.

먼저 auth을 읽었고, mod_ssl을 읽는 구조에서 mod_ssl을 읽고, auth을 읽는 구조로 변경했더니 무사하게 동작되었습니다.

Posted by 김용환 '김용환'

댓글을 달아 주세요

  1. 샴푸 2011.10.24 10:22  댓글주소  수정/삭제  댓글쓰기

    리눅스 디버깅이란건 이런거군요.. 짱!


wireshark를 ubuntu에 설치

kimyonghwan@ubuntu:~$ sudo apt-get install wireshark

프로그램 실행

kimyonghwan@ubuntu:~$ sudo wireshark


interface를 지정하고, 모니터링함. SSL에 대한 암호화되어서 자세한 내용은 알 수 없지만, 간단하게라도 SSL 을 이해할 수 있다.




Posted by 김용환 '김용환'
TAG SSL, wireshark

댓글을 달아 주세요

openssl 통신

c or linux 2011. 10. 21. 02:39



Apache Http 서버에서 443 포트(Https)를 인증서를 이용해서 서비스하는 경우가 있다.
이때 디버깅하는 방법은 openssl을 이용하는 방법이 있다.

이를 통해서 openssl의 handshaking 방법을 이해할 수 있으며, acl 이슈나 웹 서버의 설정 이슈들을 이를 통해서 확인이 가능하다. 정상적이지 않으며 아래와 같은 handshaking에서 문제가 발생할 것이다.
ssldump 나 wireshark, etheral 같은 프로그램으로도 충분히 볼 수 있다.

google.com:443 포트 즉, https://google.com:443 포트에 접속하는 연결을 하는 예제이다.
아주 전형적인 ssl 통신이다.


kimyonghwan@ubuntu:~$
openssl s_client -host google.com -port 443 -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDITCCAoqgAwIBAgIQL9+89q6RUm0PmqPfQDQ+mjANBgkqhkiG9w0BAQUFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x
MTEyMTgyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw
FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA6PmGD5D6htffvXImttdEAoN4c9kCKO+IRTn7EOh8rqk41XXGOOsKFQebg+jN
gtXj9xVoRaELGYW84u+E593y17iYwqG7tcFR39SDAqc9BkJb4SLD3muFXxzW2k6L
05vuuWciKh0R73mkszeK9P4Y/bz5RiNQl/Os/CRGK1w7t0UCAwEAAaOB5zCB5DAM
BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl
LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF
BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw
Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0
ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF
AAOBgQCfQ89bxFApsb/isJr/aiEdLRLDLE5a+RLizrmCUi3nHX4adpaQedEkUjh5
u2ONgJd8IyAPkU0Wueru9G2Jysa9zCRo1kNbzipYvzwY4OA8Ys+WAi0oR1A04Se6
z5nRUP8pJcA2NhUzUnC+MY+f6H/nEQyNv4SgQhqAibAxWEEHXw==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 1907 bytes and written 281 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: 11ABAB39B14A001469136E9C7B278415E005D44571B487BE2C04B51963F78160
    Session-ID-ctx:
    Master-Key: 21EBAA2443B524F04FDD88A53B84211C0C91F915DB06A05929BBB5F98F29F0F6D13D489A9A622B0C1C90A8A07858635F
    Key-Arg   : None
    TLS session ticket lifetime hint: 100800 (seconds)
    TLS session ticket:
    0000 - 1a b6 4a e9 9e fd 36 e2-74 0a 05 ba 4c bf b3 d3   ..J...6.t...L...
    0010 - c4 57 97 e3 fe c4 56 34-ee 19 e1 82 04 56 59 fe   .W....V4.....VY.
    0020 - 21 35 c9 e9 f6 a7 d4 5f-6e d7 d5 64 85 57 c7 18   !5....._n..d.W..
    0030 - 4a 2b 5d 2d db 09 71 96-0c 48 85 d7 5b 9f 37 ab   J+]-..q..H..[.7.
    0040 - 8a 15 27 9c 35 0c 38 e2-54 08 cd a9 4c ef c2 bb   ..'.5.8.T...L...
    0050 - cc a3 ad bf 10 03 58 3a-ba 89 d3 40 36 71 a7 d5   ......X:...@6q..
    0060 - 20 1a 5f 79 3e 4a 77 b7-9b ab 70 3c e6 7c 06 9c    ._y>Jw...p<.|..
    0070 - 21 05 3a 5c be de 3e 63-67 6c fd fd 65 5b c7 6b   !.:\..>cgl..e[.k
    0080 - 12 7c ad da d0 6d 43 6d-68 29 78 20 f2 4e 59 48   .|...mCmh)x .NYH
    0090 - 60 fb 31 1b                                       `.1.

    Start Time: 1319126774
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
get / http/1.1

HTTP/1.0 400 Bad Request
Content-Type: text/html; charset=UTF-8
Content-Length: 11782
Date: Thu, 20 Oct 2011 16:06:19 GMT
Server: GFE/2.0

<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <title>Error 400 (Bad Request)!!1</title>
  <style>
    *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{background:url(https://t1.daumcdn.net/cfile/tistory/223EEF4B56E6EB481D"BORDER-BOTTOM: #dbe8fb 1px solid; BORDER-LEFT: #dbe8fb 1px solid; PADDING-BOTTOM: 10px; BACKGROUND-COLOR: #dbe8fb; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BORDER-TOP: #dbe8fb 1px solid; BORDER-RIGHT: #dbe8fb 1px solid; PADDING-TOP: 10px" class=txc-textbox>
참고로,
ssl version2는 보약 취약성이 발견되어서 사용하지 않는다.

kimyonghwan@ubuntu:~$ openssl s_client -host google.com -port 443 -state  -ssl2
10184:error:140A90C4:SSL routines:SSL_CTX_new:null ssl method passed:ssl_lib.c:1453:






SSL은  HTTP와 TCP 중간에 걸친 Layer이며, HTTPS 연결시 SSL 통신을 하게 된다.




smtps, nntps, ldaps, ftps, pops 등 다양한 secure channel에 공통적으로 사용될 수 있다.


자세한 내용은 워낙 많은 자료들이 인터넷에 많은 관계로 참조하면 된다.

- https://developer.connectopensource.org/display/CONNECTWIKI/SSL+Handshake

- http://blog.naver.com/nttkak?Redirect=Log&logNo=20130246501
  http://blog.naver.com/nttkak?Redirect=Log&logNo=20130246501
  http://blog.naver.com/nttkak?Redirect=Log&logNo=20130246501

- http://pchero21.com/798

- http://www.openssl.org/

- http://www.ibm.com/developerworks/kr/library/l-openssl.html

- http://www.joinc.co.kr/modules/moniwiki/wiki.php/article/Openssl%C0%BB_%C0%CC%BF%EB%C7%D1_%C6%C4%C0%CF_%BE%CF%C8%A3%C8%AD



하고 싶은 얘기는 SSL Handshaking이다. 트러블 슈팅이 큰 도움이 된다.
약간 광범위한 얘기이긴 하지만. 무척이나 중요한 내용이다.

* http://www.symantec.com/connect/articles/apache-2-ssltls-step-step-part-1 의 이미지 참조


Figure 2.






이미 진행했던 구글 서버와의 openssl 통신 결과의 의미를 파악해 본다.

kimyonghwan@ubuntu:~$ openssl s_client -host google.com -port 443 -state  | more
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
CONNECTED(00000003)



이 내용을 쉽게 풀어 써볼 수 있다.

1. Client(터미널에서 openssl 요청, 브라우져)가 Https를 이용해서 Server(google.com) URL로 통신을 시도한다. Hello 라는 통신인데, 지원 가능한 암호방식, 키 교환 방법, 압축 방식을 서로 의사소통한다.

2. Server(google.com)가 인증서를 client에 전달한다.

3. Client에서는 Server 인증서 public key 얻어옴 (기본적인 인증서에 대한 검증 절차를 거침. 인증서의 도메인과 실제 요청하는 도메인이 갖은지. CA가 정확하게 인증했는지 등등)

5. Client에서는 public key를 이용한 pre-master key(RSA 키교환) 를 생성하고 서버에 전달하여 상호간의 키를 교환하도록 한다.  (key exchange)

6. Client에서 인증서 검증 정보를 보내고,  SSL 통신에 의해 결정된 암호방식, 키교환 방법, 서명방식, 압축방식을 다음부터 적용할 것을 정한다. (cipher spec)

6. Server는 Client로부터 받은 pre-master key(또는 pre master secret)를 private key로 디코딩하고 Session ticket으로 생성하고 Client에 전송한다.  (session ticket)

7. Server 에서는 Session Ticket를 이용하여 Server와 Client간의 발생하는 모든 통신은 암호화가 되게 한다.



보안쪽은 조금만 이해안되면 혼란스러운 부분이 있어서 좋은 레퍼런스를 참조한다.


통신과 키 생성원리

참조 : https://developer.connectopensource.org/download/attachments/34210577/Ssl_handshake_with_two_way_authentication_with_certificates.png





이해하기 좋은 그림이 있어서 소개한다.

참조 : http://www.kannel.org/download/kannel-wtls-snapshot/wtls.html









ssldump을 이용해서 application 단에서의 통신을 이해할 수 있다.


kimyonghwan@ubuntu:~$ sudo ssldump -a -A -H -i eth0

New TCP connection #1: ubuntu(53920) <-> hx-in-f105.1e100.net(443)
1    3.0262 (3.0262)  S>C  TCP FIN
1    3.0263 (0.0000)  C>S  TCP FIN
New TCP connection #2: ubuntu(59780) <-> hx-in-f106.1e100.net(443)
2    4.7585 (4.7585)  S>C  TCP FIN
2    4.7586 (0.0000)  C>S  TCP FIN
New TCP connection #3: ubuntu(53922) <-> hx-in-f105.1e100.net(443)
3    0.5294 (0.5294)  S>C  TCP FIN
3    0.5295 (0.0001)  C>S  TCP FIN
New TCP connection #4: ubuntu(59782) <-> hx-in-f106.1e100.net(443)
4 1  0.0519 (0.0519)  C>SV3.1(90)  Handshake
      ClientHello
        Version 3.1
        random[32]=
          4e a0 5b 72 1f f2 e5 9b fc cf 6f ab 3f 8c 03 5d
          c6 b0 23 b0 71 11 87 4d d3 ad 67 57 32 9b c7 7d
        cipher suites
        Unknown value 0x39
        Unknown value 0x38
        Unknown value 0x35
        TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
        Unknown value 0x33
        Unknown value 0x32
        Unknown value 0x2f
        TLS_RSA_WITH_RC4_128_SHA
        TLS_RSA_WITH_RC4_128_MD5
        TLS_DHE_RSA_WITH_DES_CBC_SHA
        TLS_DHE_DSS_WITH_DES_CBC_SHA
        TLS_RSA_WITH_DES_CBC_SHA
        TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
        TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
        TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
        TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
        TLS_RSA_EXPORT_WITH_RC4_40_MD5
        Unknown value 0xff
        compression methods
                unknown value
                  NULL
4 2  0.1044 (0.0524)  S>CV3.1(53)  Handshake
      ServerHello
        Version 3.1
        random[32]=
          4e a0 5b 72 79 8e 98 9b 19 71 29 5b 74 7e b8 e7
          ec 94 96 39 75 f1 21 66 f5 1b f9 29 b6 94 c1 70
        session_id[0]=

        cipherSuite         TLS_RSA_WITH_RC4_128_SHA
        compressionMethod                   NULL
4 3  0.1044 (0.0000)  S>CV3.1(1625)  Handshake
      Certificate
4 4  0.1044 (0.0000)  S>CV3.1(4)  Handshake
      ServerHelloDone
4 5  0.1061 (0.0016)  C>SV3.1(134)  Handshake
      ClientKeyExchange
        EncryptedPreMasterSecret[128]=
          bb bb 6a 34 58 49 a7 bd 98 12 17 d8 4a d0 8d f3
          ff 47 01 23 c1 15 61 d2 7d 53 70 73 5a a1 3a cb
          ae 70 51 37 cb 08 9b a4 61 14 77 b8 7b a7 3f 8e
          b4 f9 36 af ea 95 ae 0d 9e d1 db 84 5d 09 88 39
          25 06 77 ee dc e9 0a 3a 68 c0 c2 82 58 d4 b2 1b
          77 11 ca 4b 96 26 bb 7a db 9e b1 42 f2 7c ff fc
          72 ad 09 8d 72 ec 5e 0a fe a7 09 fe 2e ea 44 d8
          2d 95 0e 9f 84 e1 22 9d 64 c7 70 f0 38 72 42 34
4 6  0.1061 (0.0000)  C>SV3.1(1)  ChangeCipherSpec
4 7  0.1061 (0.0000)  C>SV3.1(36)  Handshake
4 8  0.1556 (0.0495)  S>CV3.1(158)  Handshake
      dss_fixed_dh4 9  0.1556 (0.0000)  S>CV3.1(1)  ChangeCipherSpec
4 10 0.1556 (0.0000)  S>CV3.1(36)  Handshake
4 11 9.3738 (9.2181)  C>SV3.1(35)  application_data
4 12 9.7738 (0.3999)  C>SV3.1(21)  application_data
4 13 9.8238 (0.0499)  S>CV3.1(165)  application_data
4 14 9.8238 (0.0000)  S>CV3.1(1175)  application_data
4 15 9.8239 (0.0000)  S>CV3.1(1345)  application_data
4 16 9.8754 (0.0515)  S>CV3.1(1345)  application_data
4 17 9.8755 (0.0000)  S>CV3.1(311)  application_data
4 18 9.8755 (0.0000)  S>CV3.1(1345)  application_data
4 19 9.9252 (0.0496)  S>CV3.1(1345)  application_data
4 20 9.9252 (0.0000)  S>CV3.1(1345)  application_data
4 21 9.9252 (0.0000)  S>CV3.1(141)  application_data
4 22 9.9252 (0.0000)  S>CV3.1(1345)  application_data
4 23 9.9253 (0.0000)  S>CV3.1(1345)  application_data
4 24 9.9253 (0.0000)  S>CV3.1(960)  application_data
4    9.9253 (0.0000)  S>C  TCP FIN
4 25 9.9261 (0.0008)  C>SV3.1(22)  Alert
4    9.9264 (0.0002)  C>S  TCP FIN











 

Posted by 김용환 '김용환'
TAG SSL

댓글을 달아 주세요


출처 : http://www.cyrius.com/debian/nslu2/linux-on-flash.html


centiseconds는 1/100


  • /proc/sys/vm/laptop_mode: How many seconds after a read should a writeout of changed files start (this is based on the assumption that a read will cause an otherwise spun down disk to spin up again).
  • /proc/sys/vm/dirty_writeback_centisecs: How often the kernel should check if there is "dirty" (changed) data to write out to disk (in centiseconds).
  • /proc/sys/vm/dirty_expire_centisecs: How old "dirty" data should be before the kernel considers it old enough to be written to disk. It is in general a good idea to set this to the same value as dirty_writeback_centisecs above.
  • /proc/sys/vm/dirty_ratio: The maximum amount of memory (in percent) to be used to store dirty data before the process that generates the data will be forced to write it out. Setting this to a high value should not be a problem as writeouts will also occur if the system is low on memory.
  • /proc/sys/vm/dirty_background_ratio: The lower amount of memory (in percent) where a writeout of dirty data to disk is allowed to stop. This should be quite a bit lower than the above dirty_ratio to allow the kernel to write out chunks of dirty data in one go.


 

Posted by 김용환 '김용환'

댓글을 달아 주세요