드디어 파리에서의 마지막날...

파리에서는 너무 힘들게 돌아다니지 말고 우아하면서도 느긋하고 여유있게 파리를 즐겨보자라던 계획은 온데 간데 없
이 파리 역시 전날까지 강행군의 연속이었다.

마지막날은 몽마르뜨 언덕을 다녀오는 것을 포인트로 하고, 그 전에 미술을 사랑하는 우리 애들 엄마를 위해 파리에서 꼭 들러보기로 하였던, 바스티유 광장에서 가까운 피카소 박물관을 다녀오는 일정으로 일찍 끝내기로 한다.

파리에서 묵었던 아파트형 숙소인 메종젠의 마당.
메종젠은 파리의 주택 구조의 특징이라고 하는, 큰 길에서 보면 큰 대문만 보이고 큰 문을 열고 들어오면 작은 공동 마당을 중심으로 다시 사방으로 대문들 열고 들어가도록 되어 있으며, 각각의 대문 안에 위와 같은 마당을 지나 실건물로 들어가도록 되어 있다.
 
항상 덩치 큰 두마리의 진도개 비슷하게 생긴 멍멍이들이 마당에 누워있는데, 워낙에 순한 녀석들이라 아이들이 다가가서 쓰다듬어주어도 눈만 껌벅이며 꿈쩍도 하지 않는다.
 

작은 연못과 함께 소박하지만 아름답게 꾸며져 있는 메종젠의 마당.
건물 안에는 스튜디오라고 부르는, 우리식으로 말하면 원룸 형태로 각각의 방들이 완전히 독립되어 생활할 수 있도록 되어 있다.
입실할 때 열쇠를 받아가서 퇴실하면서 반납할 때까지 완전하게 투숙객이 알아서 생활하면 되는 것이고 불편한 점이나 필요한 것이 있을 때 주인님이신 은조님에게 전화를 하면 된다. 
방에는 주위의 가볼곳, 산책로에 대한 설명, 주위 맛있는 빵집, 식당, 슈퍼 등에 대한 설명, 주요 관광지 버스 안내서 등 다양한 정보들이 준비되어 있어서 생활 및 관광 정보를 얻는데 매우 유용하다.

건물 자체는 600년이 넘은 건물이라 낡은 건물이지만 실내는 완전히 리모델링이 되어 전혀 오래된 것 같지 않은 느낌이며, 파리의 대부분의 숙소들과 마찬가지로 에어컨이 없기 때문에 더울까 걱정을 했는데 파리의 여름(8월)은 밤낮의 기온 차가 꽤 큰 편이라 생각보다는 잘 때 그렇게 덥지는 않다.
찾아보니 파리의 여름 평균 기온이 낮기 때문에 최근에 지은 호텔이 아니라면 에어컨이 있는 경우가 드물다고 한다.

무엇보다 주방 시설이 완벽하고 바로 옆에는 까르푸가 있기 때문에 저녁 반찬 거리를 사서 집에서 푸짐하게 해먹을 수 있다는 점이 가장 좋았던 것 같다.

또 한가지 중요한 장점은 휴대폰으로 거는 것만 제외하면 모든 전화(국제전화 포함)가 무료라는 것...

위치는 1호선 바스티유 역에서 걸어서 5분 정도라 주로 1호선 지하철을 많이 이용하였고, 바로 앞 버스 정유장에서도 개선문 등 주요 관광지로 가는 버스를 이용할 수 있으며, 특히 스위스 가는 리옹역 역시 5분 거리라서 아침 일찍 스위스 이동하는데도 편했다.

다만 8월 중순부터는 파리 사람들의 휴가 기간인지라 주위에 추천 빵집들 중 휴가가는 집이 많아서 정작 추천 빵집의 빵은 맛보지 못하고 온 것이 아쉬운 점이었다.

피카소 박물관 앞에서 인증샷...

아침에 느즈막이 일어나 주인님에게 연락하여 내일 아침 일찍 나가니 미리 잔금을 지불하고서 추천 빵집에 빵 사러 갔더니 지도에 나오는 모든 추천 빵집들이 다 문을 닫았다.

결국 숙소 바로 옆 빵집에서 간식으로 먹을 크로아상을 산 후 숙소 앞에서 29번 버스를 타고 마레 지구에 있는 피카소 박물관을 찾아갔다. 

그런데 이게 왠일인가....
2013년 봄까지 리노베이션을 위해 문을 닫는다는 것이다.
이거 때문에 동선 짤 때 꽤 많은 부분을 희생하고 일정에 넣은 것이었는데 미리 확인하지 못한 것이 실수였다.

아무튼 할 수 없이 아쉬움을 뒤로 하고 근처에 있는 까나발레 박물관을 들러보기로 한다.

까나발레 박물관 마당의 누리 14세 동상.
까나발레 박물관은 말하자면 파리 역사 박물관인데, 프랑스 혁명 및 근대사에 대한 전시를 볼 수 있으며 관람료는 무료이다. 
사실 한국어 가이드도 없고 전시물 설명도 다 불어라서 그다지 흥미를 끌만한 요소는 없었던 것 같고, 굳이 여기를 시간 내서 찾아올 필요는 없을 듯 하다.

박물관에 전시되어 있는 바스티유 감옥의 모형.. 
이 감옥에서의 총성이 프랑스 혁명의 시발점이 되었다고 하니 꽤 역사적 의미가 큰 건물인 듯..

까나발레 박물관 정문...

약간의 실망과 함께 박물관을 나온 후 생폴 역으로 가서 전철을 타고 몽마르뜨 언덕으로 이동하였다.

Barbès - Rochechouart‎ (읽지도 못하겠음..) 역에서 내려서 역 밖으로 나오니 이 동네는 그동안 봐왔던 시내의 프랑스랑은 분위기가 매우 다른 것이, 왠 오리지널 흑형들이 길가에 주르르 노점을 치고서서 에펠탑 열쇠고리 같은 기념품을 팔고 있다. 
솔직히 나도 살짝 겁이 나는데 이런 곳에 여자 혼자 오면 정말 많이 무섭겠다는 생각이 들었다.
여자분들만 있는 경우라면 절대 해지고 늦은 시간에 이쪽으로 오는 것은 피하는 것이 좋을 듯.. 
몽마르뜨 역에서 남쪽으로 내려오면 바로 나오는 앙베르 역(Anvers)는 그래도 분위기가 나은 듯 하니 지하철은 앙베르 역을 이용하는 것이 좋겠다. 

잠시 방향이 헷갈려서 반대 방향으로 가다가 가게에 들어가서 물어보니 반대 방향이라 알려주기에 돌아서 걷다보니 사람들이 한방향으로 몰려간다.
앙베르 역에서 몽마르뜨로 올라가는 언덕길에는 다양한 기념품 점들과 식당들이 주욱 늘어서 있어서 보는 눈을 즐겁게 해주며, 길 중간에는 곳곳에 야바위 꾼들이 자기네끼리 쇼를 하면서 지나는 사람들을 유혹한다. 

드디어 도착한 몽마르뜨 언덕과 그 꼭데기에 위치한 사크레쾨르 성당..

무언가 극적이고 낭만적인 모습의 언덕을 기대하고 갔지만 막상 가서 보니 이 조그마한 몇 미터되지 않아 보이는 작은 언덕이 이렇게 많은 관광객을 끌어모으는 걸 보면 참 신기할 뿐이다.
그래도 날씨가 너무도 좋아서 파란 하늘을 배경으로 한 성당의 경치만큼은 너무도 좋고, 서늘한 바람과 따뜻한 햇빛은 그냥 앉아만 있어도 기분이 좋아진다. 

잠시 뒤에 보이는 벤치에 앉아서 간식으로 사온 빵을 피크닉 삼아 먹고 성당을 올라가 보았다. 

빵 먹고 있는데 어디선가 갑자기 자전거 타고 나타난 여자 경찰이 집시처럼 보이는 아이들을 붙잡아서 머라하면서 데리고 가는데, MTB 자전거로 저 계단들을 쿵쾅쿵광 타면서 올라오는 모습이 참 멋지던 경찰이었다.

성당 앞까지 올라서 바라면 파리 전경..
우리나라와는 달리 주위에 산이 하나도 없는 평지라는 사실이 참 생소하게 느껴진다. 

몽마르뜨 언덕 꼭데기에 우뚝 서있는 사크레쾨르 대성당 (La Basilique du Sacre Coeur).
지붕의 모양을 보면 유럽에서 익숙한 고딕 양식이 아닌 비잔틴 양식의 독특함이 있다.
꼭데기에 세계 최대의 종이 있다는데, 여행 내내 워낙 큰 성당들에 익숙해져서인지 별로 들어가볼 생각이 들지 않아서 패스...

몽마르뜨 언덕의 높이가 겨우 130m 밖에 되지 않지만, 파리에서는 가장 높은 지대라고 한다. 
덕분에 그 꼭데기에 위치한 이 성당이 파리 전역을 내려다 볼 수 있는 장소인 셈이다 (물론 에펠탑이 더 높다...)

성당 옆에서는 몽마르뜨 언덕 주위를 한바퀴 도는 미니 기차가 운행되는데 주위 역까지 운행을 하므로 역에서 꼭데기까지 이 기차를 타고 올라올 수 있다고 한다.
가기 전에 찾아본 바로는 무료라고 하는데 타보지 않아서 정말 무료인지는 모르겠다.

어딜가나 만날 수 있는, 몽마르뜨에도 빠지지 않는 거리의 퍼포먼스... 

성당의 정면에서 광장쪽을 보았을 때 오른쪽 코너를 돌아서 길을 따라 가면 바로 몽마르뜨의 화가들의 괒장인 테르트르 광장이 나온다.

넓은 사각의 광장에는 거리의 화가들이 저마다 자신의 화풍을 뽐내며 다양한 그림들을 그려서 오가는 사람들에게 판매한다.

거리의 화가라고 우습게 볼 실력들이 절대 아니다.
간단한 그림부터 초상화 등 모두들 수신년은 내공을 쌓았을 듯한 실력을 보여준다.

대부분은 유화를 그리는 듯...

광장의 한쪽 블록은 모두 즉석에서 초상화를 그려주는 작가들인데, 가격은 대략 30~40유로 정도 받는다.
지나가다가 한국인 화가도 한분 만나서 인사를 나누었다.

내가 느끼기에 항상 실물보다는 더 예쁘게 그려주는 듯 하니 시간이 있으면 앉아서 초상화 하나 그려가는 것도 좋을 듯.

또 다른 블록에는 초상화가 아니라 즉석에서 캐리커쳐를 그려주는 화가들이 있다. 가격은 20~25유로 정도.
우리도 기념 삼아서 우리 꼬맹이 캐리커쳐를 그려보았는데, 어쩌면 그렇게 그럴싸한 특징을 콕 집어서 표현을 하는지 무척 신기했다.
근데 서양인들의 눈에 비치는 동양인의 특징 중 하나는 아마도 작게 찢어진 눈인가 보다...

광장의 중심과 또 광장을 둘러싼 사방의 블록들에는 다양한 식당과 까페들이 모여있으니 구경하다 지치면 앉아서 식사나 차를 시켜서 쉬어가기에도 좋다.

이렇게 몽마르뜨 언덕을 둘러보고 오늘은 일찍 숙소로 들어가 짐정리하고 일찍 쉬기로 하였다.

내려가는 길에 만난 언덕 아래에서 성당까지 올라가는 일종의 케이블가 같은 역할을 하는 푸니쿨라.
올라갈 때 이걸 봤으면 한번 타볼 생각이었는데 못보고 그냥 올라갔기에 그렇다고 내려올 때 타자니 올라간 수고가 아까워서 결국 못타봤다.
하긴 언덕이 힘들다는 사람들도 많지만 애들 데리고 올라가는데 사실 왠만한 저질 체력이 아니라면 그렇게 힘든 거리는 아닐 듯 싶다. 

여러 파리 여행 후기에서는 몽마르뜨 언덕에 소매치기도 많고 험상궂은 흑형들도 많아서 조심하라는 얘기들도 많지만 우린 네식구가 몰려다녀서인지는 몰라도 관광객들이 많긴 해도 그렇게 위험하거나 위협을 느낄만한 분위기는 보기 힘들었다.
물론 해지고 야간에 오면 동네 특성 상 좀 그럴지 몰라도 대낮의 몽마르뜨는 그냥 사람들 다니는 길로 다니면 크게 위험한 장소는 아닐 듯 하다. 

언덕을 내려와 앙베르 역에서 지하철을 타고 바스티유에 내려 광장 바로 앞에 있는 빵집에서 내일 스위스로 가는 길에 먹을 크로아상을 사서 숙소로 돌아오니 4시반...
남아있던 과일들을 마저 깍아먹고 나 혼자 리옹역으로 가서 내일 아침에 스위스로 이동할 TGV 티켓을 찾아왔다.

TGV 티켓을 찾을 때는 키오스크를 이용하면 되는데 이때 주의할 점이 메일로 받은 예약번호를 입력한 후 예약할 때 결재하였던 신용카드를 넣어야 하므로 예약한 신용카드를 반드시 잘 챙겨와야 한다. 

메종젠에서 길을 건너 한블록만 가면 나오는 빨래방..

숙소에서 다들 피곤함에 잠시 눈을 붙이고 일어나서, 벌써 2주나 입어서 더이상 입을 옷이 없었던 관계로 메종젠에서 안내해준 코인 빨래방을 이용해보기로 하고 옷가방을 들고 숙소를 나섰다. 

대략 6kg에 3.5유로라는데 도대체 국내에서도 빨래방이란 걸 이용해본 적이 없는 우린 한참을 설명서를 보며 헤매고 있었는데, 한 젊고 잘생긴 흑인 친구가 들어오더니 자기 빨래를 넣고서는 우릴 보고 도와주겠다고 한다. 
심지어 자기 돈으로 세제(따로 동전을 넣어서 사야 하는..)까지 사서는 우리 빨래에 넣어주고 동작까지 시켜주는데 어찌나 고마운지...다시 한번 파리 사람들이 불친철하다는 소리는 다 거짓말이야... 라고 생각했다.

빨래하는데 탈수까지 예상 시간은 한시간 정도...
탈수 후에 건조기는 따로 동전을 넣어서 말려야 하는데 성능이 좋지는 않아서 세번인가를 해서 겨우 말릴 수 있었다.
 
기다리는 시간 동안 메종젠 까페에서 은조님이 추천하셨던 공중 산책로(?)인 Promenade Plantée를 다녀오기로 한다.

산책로는 빨래방 건너편 길에 위와 같이 굴다리 처럼 되어 있는 부분의 위로 주욱 연결되어 있으며, 굴다리 아래는 사진처럼 막아서 공방으로 사용된다.

이 시간에도 조깅을 하는 파리지앵들을 꽤 많이 볼 수 있다.  

공방 왼쪽으로 산책로로 올라가는 계단이 있으며, 계단을 오르면 이렇게 공중 정원같은 산책로가 시작되며, 이 길은 벵센느 숲이란 곳까지 연결되어 호수가 산책을 할 수도 있다고 하는데, 우린 한 20분 걷다가 시간이 너무 늦어서 되돌아 왔다. 
시선이 높아서 날씨 좋은 낮 시간에 여유를 가지고  주위 구경하며 산책해보면 좋을 듯...

산책로에서 바라본 거리...
왼쪽 빨간 차양이 있는 식당이 첫날 도착해서 메종젠의 은조님께서 추천하여 점심을 먹었던 메종젠에서 3분 거리에 잇는 식당인 Les Artisans ... 
서빙하는 웨이트리스 아가씨도 친절하고 영어도 잘하고, 음식도 훌륭했던 식당이라 파리에서의 첫인상으로 너무 좋았던 기억이 난다. 

산책로에서 돌아와 빨래를 건조시켜서 숙소로 돌아오니 벌써 9시...
대강 남아있는 식료품들로 저녁을 때우고 다음날 스위스로 가는 7시20분 기차를 위해 일찍 잠자리에 든다.  

출처 :  http://crazycats.tistory.com/233 

근력 위주의 라이딩은 쉽게 다리 근육을 피로하게 만들고, 그로 인해 정작 힘을 발휘하려고 할 때는 힘을 쓰기 어려운 상황이 되기 쉽습니다.

즉 결론적으로 근력(높은기어비 주행, 페달찍어누르기)보다는 회전력 위주로 타는 것이 더 효율적이라는 의미겠죠. 그럼 오늘 포스팅은 끝? ㅋㅋ 

회전력 위주로 라이딩을 하면 회전력 능력이 심폐지구력을 높여주고, 높은 회전력의 유지는 유산소성 능력을 향상시켜 줍니다.  

중,장거리 (50~100km이상) 라이딩시 근력 위주의 라이딩은 2시간을 유지하기 어렵고, 저하된 체력은 느린 회복으로 더욱 힘들어지게 됩니다.

필요 이상으로 무거운 기어(고속기어, 8단기어쪽)로 라이딩 하는 사람들을 보면 빨리 달릴 수 있을 것 같지만 근력의 의존도가 높아서 신체손실(피로도)이 늘어나며, 라이딩 중에 회복시간이 길어져 결국에는 손해를 보게 됩니다. 결국은 목표지점에 도달하지 못하고 후반에 퍼지게 됩니다.

라이딩 초반에 근력이 없어서 뒤에 쳐져 가는 사람은 없습니다. 초반 분위기대로 근력위주의 라이딩을 하게 되면 일정거리 후 또는 언덕 시작부분에서 힘의 고갈과 느린 회복으로 랩타임이 늘어나기 십상입니다.

한달 이하의 근력위주 초보자(interval spoter: 반짝 급가속자)라면 한강에서 마라톤하는 사람을 따라 잡은 후 멀찌 감치 가서 담배를 1/3 정도 피거나 물 한모금 마시고 있으면 곧 마라토너에게 추월당하는 일을 한두번쯤 경험해 보았을 것입니다. 

 

그렇다면 초보라이더는 어떻게 페달링을 해야 효율적인 라이딩을 할 수 있을까요?

우선 가벼운 기어(저속기어,로우기어,1단기어쪽)를 사용합니다. 낮은 기어(2단*4단)에 세팅하고 평지나 언덕구간을 변속 없이 달리는 방법입니다.

평지에서는 다리에 힘이 들어가지 않아서 빨리 달릴 수 없을 것 같지만 시속 20km(2*4)까지는 무난히 낼 수 있으며 이론상으로 2*7단에 이르면 35km까지도 낼 수도 있습니다.

그 정도의 회전력을 꾸준히 낼 수 있다면 언덕도 쉽게 오를수 있습니다. 

초보라이더는 2*4 기어로 RPM 90을 유지하면서 1시간 이상 꾸준히 탈 수 있어야 하고 동일 기어로 평지던 언덕이던 기어변속 없이 달릴 수 있다면 기어를 한단계 올려서 같은 방법으로 훈련을 하시면 됩니다. 이것이 우리가 말하는 엔진 업글이겠죠?

초심자들은 대부분 평지에서는 높은 기어로 페달링을 하고 언덕이 나오면 낮은 기어로 페달링을 하여 라이딩을 합니다. 이는 엔진 업글에 기여도가 낮으며 장거리 라이딩시 체력적으로 문제가 됩니다.

1. 페달링의 기본

여러 사람들과 자전거를 타고 업힐을 하다보면 중간 또는 막판에 자전거에서 내리게 되는 경우가 많은데 그때 사람들은 자신의 자전거 실력이 부족하거나 힘에 부쳐서 그런거라고 생각합니다.

정작 자신의 페달링에 문제가 있다고 생각하는 사람은 그리 많지 않습니다. 페달은 밟으면 무조건 돌아갑니다. 중요한건 어떻게 밟느냐가 관건이겠죠.

2. 페달링 속도

페달링 속도는 분당 회전수 (RPM:Revolutions Per Minute)으로 나타내는데 이것은 분당 페달이 몇 바퀴 회전했는가를 의미합니다. 이 페달링 속도를 높여주는 것이 자전거를 효율적으로 타기 위한 첫걸음입니다. 

페달링 속도를 측정하는 방법은 다음과 같습니다.  

우선 오직 한쪽 발만을 생각합니다. 오른발을 선택했다면 오른발이 위(12시방향)에서 원을 그리며 내려갔다 올라오는 것이 바로 1회전(360도)입니다. 1분 동안 오른발이 몇 번이나 회전하는지를 세어보면 자신의 페달링 속도를 알 수가 있습니다. 

1분이 측정하기 길다면 10, 20, 30초 동안 오른발이 올라오는 횟수에 6, 3, 2를 곱해주면 그것이 페달링 속도(RPM,회전력)가 됩니다. 위에 언급한대로 이것을 일정시간 유지할 수 있어야 합니다. (기본적으로 약 1시간 정도)

3. 페달링 속도는 빠를수록 좋다! (80~100)

초보자인 경우 자전거를 무조건 힘으로 속도를 내려고 합니다. 

하지만 힘으로 타는 것만큼 나쁜 습관은 없습니다. 
힘으로 타면 초반에는 순간적(1분? 100M?)으로 빨리 달릴 수 있지만 오래 유지하며 탈 수는 없습니다.
특히 중장거리 라이딩에서 힘(근력)이 아무리 좋아도 페달링 속도가 빠른 사람을 따라 잡기는 어렵습니다. 더구나 힘에는 한계가 있어 장거리 라이딩에서는 쉽게 지치게 되죠.

또한 힘으로 타면(무산소운동) 앞쪽 무릎인대에 강한 압력이 가해져 무릎 부상을 초래할 수 있고 다리 근력만 강해져 허벅지가 굵어지게 됩니다. 
이와는 반대로 회전력(페달링)으로 타면(유산소운동) 자전거 타는 능력은 향상되고 다리에 무리도 가지 않으면서 심폐기능이 좋아지며 미용(다이어트)효과를 볼 수 있습니다.

 

4. 효율적인 페달링 속도

사실 가장 효율적인 페달링 속도는 개개인마다 차이가 있지만 일반적으로 70~90RPM 사이가 가장 효율적인 페달링 속도라 할 수 있습니다. 고수들의 경우 90RPM 이상을 유지하고 긴 오르막에서조차 70RPM 밑으로 떨어뜨리지 않습니다.
일반적으로 장거리를 달리려면 80RPM 정도는 유지해 주는 것이 좋습니다.

일반인과 고수의 페달링 차이를 보면 일반인은 페달링 속도가 언덕에서 급격히 떨어지는 경우가 많지만 고수들은 일반도로와 언덕 초반에 페달링 속도가 거의 변화가 없고 아주 빠르진 않아도 언덕에서도 일정한 페달링 속도를 계속 유지하며 오르는 것을 볼 수 있습니다.

5. 페달링 속도 높이기

페달링 속도를 높이기 위해서는 꾸준한 연습이 필요합니다. 연습만이 살길! ㅋㅋ
연습 방법은 다음과 같습니다.  

처음 자전거를 탈 때 낮은기어(저속,로우기어)에서 출발을 합니다. (예를 들면 2*4)
페달을 천천히 돌리기 시작해서 점차 속도를 빨리 합니다. 
엉덩이가 들썩 거릴 정도나 헛발질이 될즈음까지 빨리 돌리게 되면 페달링 속도를 약간 줄인 후 몇분동안 그 페달링 속도를 유지합니다. 이때가 70~90RPM 정도입니다. 

이러한 상태에서 한시간 정도(20km) 정도를 탈 수 있다면 현재 셋팅된 기어비가 자신의 기어비가 되는 것이라 보면 됩니다.

물론 라이딩 중간에 일시적으로 오르내리막에서 2*3 혹은 2*5로 변속할 수도 있습니다.

페달링에 힘이 든다면  낮은 기어비(2*3)로 바꾸어 주고 힘이 남으면 2*5, 2*6, 2*7로 올리면 됩니다. 여기서 본인이 주로 쓰는 기어비가 자신의 적정기어비라고 보면 됩니다.

위에서 잠깐 언급한대로 엔진의 업글(upgrade)이 된다는 의미는 주기어비가 2*4인 사람이 현 기어비에서 여력이 생기면 2*5로 한단계를 높이고 다시 2*6으로 2*7로 올려가는 것을 의미합니다 .

일반적으로 2*4로 평지에서 타게 되면 15~20키로의 속도까지가 나올 수 있지만 초보자들은 1시간이상 라이딩시 대개 90RPM에서 20키로 정도의 속도나오기가 어렵습니다.

기어(변속기)라는 것이 속도를 올리기 위해 있는 것이라고 생각하기 쉬우나 속도를 올리는 것보다는 일정한 RPM(페달링,회전력)을 유지하기 위해 있다고 보셔야 합니다.

평지에서 2*4 기어로 달리던 라이더가 언덕에서 2*4에서 올라가려고 하면 RPM이 떨어지게 됩니다. 이때 초보자는 힘을 주어 근력으로 오르려고 합니다. 
그러나 페달링의 정석은 2*4에서 힘들다면 2*3, 2*2 등으로 기어를 낮추어서(낮은,가벼운기어비)평지 RPM을 근접, 유지하는 것입니다.

평지에서도 마찬가지로 예를 들어 2*4의 기어로 90RPM으로 가다 힘이 들면 2*3으로 낮추어서 평균 90RPM을 유지하며 근육에 피로를 풀고 힘을 축적하면서 라이딩을 하는 것이 정석입니다.

한달 정도 위와 같은 페달링을 하면 기본 70~90RPM은 본인 몸에 익숙한 횟수가 됩니다. 어떤 상황에서도 다리는 그 페달링 속도를 유지하게 되는 것이죠.

 

통상 21/24/27단이니 하면서 장삿속으로 자전거를 팔고 있지만 (높은 숫자를 좋아하는 심리 이용)

실제로는 7/8/9단의 자전거를 의미합니다. 자동차로 치면 4,5단 차라 보면 됩니다. 다만 변속의 용이성을 위해 기어비가 더 많이 있는 것입니다. 우리 몸은 기계가 아니니까요.^^

 

앞기어 1~3단은 자동차의 오토기어로 생각하면 쉽습니다.

앞1단(저속,낮은,가벼운기어,몸쪽기어,작은기어) -> L(저속으로 높은언덕) 

앞2단(보통,일반주행기어,가운데기어,중간기어)  -> D(일반시내주행,보통 이 기어를 대부분 사용) 

앞3단(고속,높은,무거운기어,바깥쪽기어,큰기어) -> H(고속도로) 

뒤1~7,8,9 (저속->고속으로, 가벼운->무거운쪽으로, 몸쪽->바깥쪽으로)

몸쪽기어는 가볍고 저속인 반면 몸바깥쪽은 고속, 무거운 기어로 생각하면 됩니다. 톱니의 크기를 생각하면 안됩니다.

일반적으로 한강자전거 도로나 시내주행시(약한 언덕)에는 2단에서만 주행하여도 충분합니다. 시내운전시 D만 사용하듯이...

이론상 2*7단에서 90RPM 유지시 25Km 이상 나올 수 있으므로...

RPM 유지시에는 2*3/2*4/2*5/2*6에서 해결이 됩니다.

일반주행시 앞2단에서 뒤3/4/5의 기어비를 사용하다 힘에 여력이 있으면 앞 3단 뒤5/6/7 정도로 넘어가고 언덕 주행시는 앞2,  뒤5/4/3 정도 가다가 그래도 언덕이 남아있으면 앞2에서 뒤3/2/1로 가는 것이 아니라 앞1과 뒤3/2/1로 가는 것이 옳은 기어변속입니다.

이렇게 한다면 절대로 3-1, 1-8이라는 기어비를 사용할 일이 없습니다.

고로 앞1은 뒤3/2/1 정도 사용하고, 앞2는 뒤3/4/5 정도,  앞3은 5/6/7 정도로 사용하면 됩니다.

 

21단,24단,27단 자전거의 속도(Km) (휠26인치, 타이어1.95 회전수90RPM)

일반적인 9단기어 MTB

로드사이클 컴팩트 크랭크 기어비

Chaper.5 FAQ

이 FAQ는 뉴스그룹 comp.infosystems.www.servers.unix와 mod_ssl 지원을 위한 메일링 리스트인 sw-mod-ssl@engelschall.com에 올라왔던 질문들을 모은 것이다.

About the module

mod_ssl과 Apache-SSL은 어떻게 다르며, mod_ssl은 어디에서 출발한 것인가? [L]

mod_ssl은 Apache-SSL에 비해 많은 변화가 있었으며, 자세한 내용은 mod_ssl 배포판의 CHANGES와 CHANGES.20 파일을 참조한다. 그 대부분은 내부적인 변경이나 소스 코드의 변경이며, 밖으로 보여지는 주요한 변화는 다음과 같다 :

mod_ssl은 Apache-SSL에서는 제공하지 않는 완전한 사용자 매뉴얼을 제공하며, 여기에는 모든 Configuration directives, 환경변수(environment variable) 그리고 그 외의 많은 것들에 대하여 기술하고 있다. 또한 mod_ssl은 Apache/SSL/SSLeay 에 대한 FAQ를 제공하며, FAQ에서는 CA를 설정하는 법, 서버 증명서(Server Certificate)를 생성하는 법 등등에 대한 자세한 설명을 제공한다.

Mod_ssl은 사용자들이 backdoore나 security hole 등을 찾아보는데 도움이 될 수 있도록 소스 코드에 자세한 설명을 덧붙이고 있으며, 이것은 보안에 관련된 소프트웨어에 있어서 매우 중요하게 고려되어야 할 사항이다. Mod_ssl 패키지의 소스 코드는 Apache의 코딩 스타일을 따르고 있으며, API의 단계를 논리적으로 따른다.

Mod_ssl은 SSL을 구현하기 위하여 Extended API를 사용하며, Apache kernel에 SSL 암호화에 관련된 코드를 직접 패치하는 것이 아니라 EAPI를 패치함으로써 커널과 mod_ssl이 서로 독립적이 될 수 있도록 하였다. 이로 인하여 SSL과 암호화에 관련된 코드는 단지 SSL 모듈 자체(src/modules/ssl/ 디렉토리)에만 존재하게 되며, Apache 커널에서 직접적으로 SSL을 참조하지 않는다.

Mod_ssl은 Dynamic Shared Object(DSO) 기능을 지원하며, DSO의 지원으로 run-time 시의 유연성(flexibility)을 최대한 높일 수 있게 된다. 즉, Apache를 컴파일할 때 SSL을 Apache 실행파일(httpd)에 넣을 것인가 넣지 않을 것인가를 결정할 필요가 없으며, 단지 필요하면 mod_so가 제공하는 LoadModule directive를 이용하여 mod_ssl을 로딩하면 된다. 이 기능은 두가지 면에서 매우 유용하다: Vendor package maintainer에게 유연성 있는 패키지를 만들 수 있는 방법을 제공하며, Apache 사용자에게 있어서는 하나의 Apache만을 설치하고서 하나 이상의 Apache(SSL을 사용하는 Apache와 SSL을 사용하지 않는 Apache)를 실행할 수 있게 해준다.

Mod_ssl은 Win32 플랫폼에서 동작하며, 이는 Apache와 SSLeay이 Wind32 플랫폼에서 동작함에 의해서 가능하다. mod_ssl은 이 패키지들의 발전을 따르고 있으며, 이 귀찮은 플랫폼에서도 항상 요구되는 지원 사항들을 제공한다. Unix/DSO의 경우와 같이 Win32에서도 mod_ssl은 mod_so의 LoadModule directive에 의해 로딩될 수 있는 표준 DLL을 통해 Apache에 적용되어진다.

Apache-SSL이 사용자로 하여금 직접 patch나 cp와 같은 명령어를 사용하게 만들었던 것에 비하여 mod_ssl은 자동화된 설정 환경을 제공함으로써 매우 쉽게 Apache 소스 트리에 적용되어진다. 이를 위하여 mod_ssl은 Apache 1.3이 제공하는 Autoconf-style Interface(APACI)를 지원한다. 또한 mod_ssl은 RSAref를 사용할 수 있으며, SSLeay가 어느 위치에 설치되었는가를 상관하지 않는다.

Apache-SSL은 mod_ssl과 같은 Apache 소스 트리에 적용하기 위한 손쉬운 방법을 제공하지 않으며 어느정도의 수작업 편집과 patch 작업이 필요하다. Configuration을 할 때와 Install을 할 때 Apache-SSL은 Apache 1.3의 Autoconf-style Interface(APACI)에 쉽게 통합되어질 수 없으며, 이미 설치되어 있는 SSLeay와 out-of-the-source-only SSLeay와의 차이점을 자동으로 인식하지 않는다. 또한 SSLVerifyClient의 인수로 이름 대신에 0에서 2까지의 숫자를 사용하는데, 그 이유는 내부적으로 enum이 사용되었고 또한 CustomLog의 %{version}c construct에 대한 결과값으로 SSLeay 0.9에서는 “SSL2”, “SSL3” 등을 사용하는 것에 비하여 SSLeay 0.8에서는 “2”, “3”을 사용되었기 때문이다.

Mod_ssl은 Apache-SSL에서 제공하지 않았던 몇가지 기능을 덧붙였다:

Mod_ssl은 log level에 따른 SSL 전용 로그 파일을 제공하며, ‘error’ level의 메시지는 자동으로 Apache 에러 로그 파일에 중복해서 기록한다. 또한 occuring system과 SSLeay 에러 메시지는 자동으로 mod_ssl 메시지에 덧붙여지며, 부가적으로 mod_ssl은 매우 자세한 힌트와 함께 SSLeay 메시지를 기록한다. Mod_ssl은 암호화된 개인키 파일들의 handling에 있어서 매우 새로운 기능을 제공한다. 먼저, 개인키를 permanent memory pool에 저장함으로써 Apache를 완전히 죽이지 않고서도 서버를 재시동할 수 있게 되었다. 두번째는 pass-phrase dialog가 훨씬 사용하기 편리하고 기능이 향상되었다: pass-phrase를 입력받는 횟수를 줄이기 위해 pass-phrase reuse algorithm을 사용하며, 틀린 pass-phrase를 인식하여 재시도할 수 있게 하며, pass-phrase를 일괄 입력하기 위하여 pass-phrase를 제공하는 외부 프로그램을 사용할 수 있는 interface를 제공한다. Mod_ssl이 제공하는 SSLCACertificateReqFile directive는 클라이언트가 서버 인증의 속도를 높이기 위해 서버로부터 CA Certificate를 로딩하는데 사용되는 SSLv3 feature를 위한 differect set of CA Certificates를 설정하는데 사용된다. Apache 내에서 외부 프로그램을 제어하는 것이 그다지 믿을 만하게 동작하지 않기 때문에, Mod_ssl은 Apache-SSL에서 SSL 세션을 저장하기 위해 사용하는 “gcache” 기능을 더욱 강력한 DBM 기반의 솔류션으로 대체하였다. 부가적으로 이 cache에 대한 inter-process access를 동기화하기 위하여 “mutex”를 사용한다. Mod_ssl은 SSLeay와 RSAref를 함께 조합하여 사용할 수 있는 기능, 즉 RSAref 패키지를 이용하여 Apache에서의 SSL Extension을 구현할 수 있는 기능을 제공한다. SSLRequire directive는 임의의 boolean expression의 조합을 접근 제어의 조건으로 사용할 수 있게 해준다. Apache Proxy Module(mod_proxy)에 대한 HTTPS 기능을 지원한다. Mod_ssl은 Win32 Apache에 대한 SSL Extension으로서는 처음으로 소스를 공개한 패키지이다.

mod_ssl에 대한 더 자세한 내용은 mod_ssl 배포판에 포함되어 있는 CHANGES 파일과 CHANGES.20 파일을 참조하기 바란다.

그렇다면 지금부터 Apache-SSL을 사용하지 말아야 하는가? [L]

그렇지 않다. 단지 mod_ssl을 사용할 수 있음을 의미할 뿐이다. 잘 알려져 있는 SSL 솔류션인 Apache-SSL은 여전히 필요한 기능을 훌륭히 수행하며, Ben Laurie는 아직도 이 패키지의 관리를 위해 많은 일들을 하고 있다. 단지 중요한 차이점은 Ben Laurie의 목적과 Ralf S. Engelschall의 목적이 다르다는 것이다. 만약 두 패키지의 차이점에 대하여 별로 필요성을 느끼지 않는다면 굳이 mod_ssl로 업그레이드할 이유는 없다. 단지 Apache-SSL을 사용하는 것이 편하게 느껴진다면 Apache-SSL을 사용하는 것이고 그렇지 않다면 mod_ssl이나 더 나은 기능을 제공하는 다른 상용 SSL 솔류션을 사용하라는 것이다. 다시 말해서 어떤 솔류션이 다른 것들보다 낫다고 말할 수는 없으며, 어느 것을 사용하는가는 개인적인 요구사항에 달려있는 것이다.

On which Apache-SSL version is mod_ssl actually based? [L]

Mod_ssl은 본래 1998년 4월 Apache-SSL 1.17 버전을 Apache 1.2.6에서 Apache 1.3b6로 포팅하는 작업에서 만들어졌다. Ben Laurie의 개발 사이클과 맞지 않음으로 인하여 mod_ssl은 기존의 mod_ssl과 새로운 Apache-SSL 1.18을 조합하여 Apache 1.3.0을 위한 버전으로 태어나게 되었다. 이 시점부터 mod_ssl은 독자적인 개발을 하게 되었으며, Apache-SSL에서 개선되는 부분들은 이후 mod_ssl이 받아들이는 방식으로 진행되어져 왔다. 다시 말하면, mod_ssl은 가장 최신의 Apache-SSL에 기반을 두고 있으며, Apache-SSL에서 개선되는 부분들을 항상 받아들이게 될 것이다.

Why is mod_ssl's version starting with 2.0.0? [L]

Mod_ssl 프로젝트가 Apache-SSL 프로젝트의 일환으로 계획되어진 것이었으며, 원래는 mod_ssl을 Apache-SSL 2.0.0에 넣고자 하는 의도였으나, Ralf S. Engelschall과 Ben Laurie가 mod_ssl과 Apache-SSL을 합치지 않겠다고 결정함으로써 mod_ssl 프로젝트는 “mod_ssl”이란 이름으로 새로운 패키지로서 발표되었다. 그러나 mod_ssl이 “second generation” 이란 의미를 표시하기 위해 첫번째 mod_ssl의 버전은 2.0.0으로 결정되게 되었다.

How do I know which mod_ssl version is for which Apache version? [L]

그것은 간단하다. Mod_ssl은 <mod_ssl-version>-<apache-version>으로 구성된 버전 표기를 하며, 예를 들면 2.2.0-1.3.4는 mod_ssl 버전이 2.2.0이며 Apache 버전 1.3.4를 위한 것임을 의미한다. 또한 이는 이 mod_ssl 버전을 정확히 이 Apache 버전에만 적용할 수 있음을 의미한다.

Is mod_ssl Year 2000 compliant? [L]

Mod_ssl은 Y2K 문제를 해결하였다.

Mod_ssl은 내부적으로 년도를 2자리로 표시하지 않으며, 시간의 표시를 현대의 대부분의 유닉스 시스템들이 사용하고 있는 시간 표시 방식인 ANSI C & POSIX numeric data type인 time_t 형식을 사용한다. 이 형식은 1970년 1월 1일 00:00 UTC로부터 지금까지의 초(second) 단위 시간을 가지고 있는 signed long 정수(보통 32bit)로 시간을 표시한다. 이 수는 2000년이 아니라 2038년1월초에 overflow가 발생한다. 또한 날짜와 시간의 표기(예를 들어 “%{TIME_YEAR}” )는 2자리 숫자로 표기하지 않고 4개의 숫자로 표기한다.

부가적으로, Apache 그룹의 2000년 문제에 대한 발표에 따르면 Apache 웹 서버는 2000년 문제의 영향을 받지 않는다. 그러나 SSLeay나 OS ( Unix 혹은 Win32 platform)이 2000년 문제의 영향을 받지 않는가의 문제는 여기서 답변될 내용이 아니다.

What about mod_ssl and the Wassenaar Arrangement? [L]

“Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies”는 재래식 무기, dual-use good과 technology에 대한 무역을 통제하기 위해 1995년에 설립된 국제기구(international regime)로서 기존에 있던 기구인 “CoCom”을 대체한 기구이다. 다음의 33개 가맹국이 있다: Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Republic of Korea, Romania, Russian Federation, Slovak Republic, Spain, Sweden, Switzerland, Turkey, Ukraine, United Kingdom and United States. 자세한 내용은 “http://www.wassenaar.org” 사이트를 참조한다.

간단히 말해서 “Wassenaar Arrangement”의 목적은 국제적 혹은 지역적인 안보와 평안을 위협하는 군사적 능력(military capability)을 제어하는데 있다. “Wassenaar Arrangement”는 암호학 (Cryptography)을 하나의 dual-use good으로서 제한하고 있으나 mass-market software와 free software에 대해서는 수출 제한에서 면제하고 있다.

현재 Wassenaar의 “GENERAL SOFTWARE NOTE(GSN)”에 대한 “List of Dual Use Goods and Technologies And Munitions”에 따르면, public domain에 속하는 소프트웨어는 제한하지 않는다고 되어 있다. 또한 “DEFINITIONS OF TERMS USED IN THESE LISTS”에는 다음과 같은 정의가 있다. “in the public domain : This means "technology" or "software" which has been made available without restrictions upon its further dissemination. N.B. Copyright restrictions do not remove "technology" or "software" from being "in the public domain".”

“Wassenaar Agreement”에 따르면 mod_ssl과 SSLeay는 public domain에 속하게 되며, 따라서, mod_ssl과 SSLeay는 Wassenaar Agreement에 영향을 받지 않는다..

　

About Configuration

I want to run HTTP and HTTPS on the same machine. Is that possible? [L]

두가지 방법이 있다: 두개의 서버를 따로 실행하거나 하나의 서버에 두개의 서비스를 실행한다. 두개의 서버를 실행해야 할 특별한 이유가 없는 한, 하나의 instance에서 SSL을 필요로 하는 virtual host에 대해서만 SSL을 적용하는 방법을 사용하는 것이 간단하다. 만약 두개의 서버를 따로 실행하는 경우에는 그 두개의 서버가 각각 허용된 포트(보통 HTTP는 80, HTTPS는 443)에만 bind를 시도하도록 되어 있는가를 확인해야 한다.

I know that HTTP is on port 80, but where is HTTPS? [L]

어느 포트에서든지 HTTPS를 실행할 수는 있지만 표준 HTTPS 포트는 443번이며, 브라우져는 기본적으로 이 포트를 찾도록 되어 있다. 브라우져가 443번이 아닌 다른 포트를 찾도록 하기 위해서는 다음과 같은 URL을 사용한다(포트가 666인 경우):

https://secure.server.dom:666/

How can I speak HTTPS manually for testing purposes? [L]

보통 Apache의 HTTP 프로토콜을 간단하게 테스트할 때 다음을 이용한다.

$ telnet localhost 80

GET / HTTP/1.0

그러나 HTTPS의 경우에는 SSL 프로토콜이 TCP와 HTTP 사이에 위치하기 때문에 HTTP와 같이 쉽지 않다. 하지만 SSLeay가 제공하는 s_client 프로그램을 이용하여 HTTPS에 대해서도 HTTP와 비슷한 테스트를 할 수 있다:

$ s_client -connect localhost:443 -state -debug

GET / HTTP/1.0

실질적인 HTTP 응답(response) 이전에 SSL handshake에 대한 자세한 정보가 보여지게 된다. Apache가 80번과 443번 포트에서 제대로 동작하고 있는가를 체크하기 위해서는 다음과 같은 cURL tool을 사용할 수 있다.

$ curl http://localhost/ (80번 포트)

$ curl https://localhost/ (443번 포트)

Why does my browser hang when I connect to my SSL-aware Apache server? [L]

“https://” 형태의 URL이 아닌 “http://” 형태의 URL을 사용하였을 수 있다. 이 경우 Apache 에러 로그파일에 “SSL_Accept failed error: 140760EB: SSL routines: SSL23_GET_CLIENT_HELLO: unknown protocol” 이라는 메시지가 나타나게 된다. 또한 이러한 현상은 SSL을 지원하지 않는 서버에 “https://” 접속을 시도하는 경우에도 나타난다. 이러한 경우에는 해당 가상 서버(virtual server)가 SSL을 지원하고 있나를 확인해 본다.

How can I use relative hyperlinks to switch between HTTP and HTTPS? [L]

URL을 변경하기 위해선 보통 Fully-qualified 하이퍼링크를 사용해야 하지만 mod_rewrite의 URL manipulation 기능을 이용하여 상대 경로(relative URL)를 사용하면서도 동일한 효과를 얻을 수 있다:

RewriteEngine on

RewriteRule ^/(.*):SSL$ https://%{SERVER_NAME}/$1 [R,L]

RewriteRule ^/(.*):NOSSL$ http://%{SERVER_NAME}/$1 [R,L]

이 rewrite 규칙은 다음과 같은 형태의 하이퍼링크를 사용할 수 있게 해준다:

<a href="document.html:SSL">

　

About Certificates

What are RSA Private Keys, CSRs and Certificates? [L]

RSA 개인키는 암호화되어있는 메시지를 복호화 하는데 사용하는 디지털 파일이다. RSA 개인키는 그에 대응되는 공개키가 존재하며, 이 공개키는 증명서를 통하여 공개적으로 배포되어서 다른 사람들이 그 공개키를 가지고 메시지를 암호화하여 공개키의 주인에게 전송하게 된다. Certificate Signing Request(CSR)은 증명서를 발급받기 위한 요청서로서 그 사람의 공개키와 이름을 포함한다. 이 CSR을 CA에게 보내면 CA가 CSR을 실재로 사용할 수 있는 증명서(real Certificate)로 만들어 주게 되는데, 이 증명서에는 CSR을 보낸 사람의 공개키, 이름, 증명서를 발급한 CA의 이름이 들어 있으며, 그 CA에 의해서 서명 된다. 이 CA를 알고 있는 브라우져는 증명서의 서명을 확인할 수 있으며, 서명이 확인되면 증명서에 들어있는 RSA 공개키를 얻게 된다. 브라우져는 이렇게 얻은 공개키를 이용해서 그 공개키의 주인만이 복호화할 수 있는 메시지를 전송한다.

Seems like there is a difference on startup between the original Apache and an SSL-aware Apache? [L]

Mod_ssl을 적용한 Apache를 시동하는 것은 SSL 개인키가 pass phrase를 필요로 하는 경우 pass phrase를 요구하는 dialog가 먼저 실행되는 것을 제외하고는 일반적인 Apache를 시동하는 것과 거의 유사하다.

Pass phrase를 수동으로 입력하는 것은 서버 시스템의 부팅 시에 Apache를 시동하는 경우 문제가 될 수 있는데, “How can I get rid of the pass-phrase dialog at Apache startup time?”에 설명된 단계를 따름으로써 이를 해결할 수 있다.

How can I create a dummy SSL server Certificate for testing purposes? [L]

서버 증명서가 반드시 잘 알려져 있는 public CA에 의해 서명될 필요는 없으며, 자신의 공개키가 포함된 증명서를 서명하는데 자신의 개인키를 사용할 수 있다. 이렇게 생성된 증명서를 자신의 서버에 설치하게 되면, 이 서버에 접속한 브라우져에는 이 증명서를 받아들일 것인가를 묻는 경고 메시지가 보여지게 되며, OK 버튼을 누르면 서버에 접속할 수 있다.

Apache를 설치할 때 “make install” 명령으로 Apache를 install하기 전에 먼저 Apache 소스 트리의 가장 상위 디렉토리에서 “make certificate” 명령을 이용하여 self-signed SSL Certificate를 생성할 수 있다. 이 증명서는 30일간 사용할 수 있으며, 또한 암호화되어지지 않는다(즉, Apache를 시동할 때 pass phrase를 묻지 않는다).

BUT REMEMBER: YOU REALLY HAVE TO CREATE A REAL CERTIFICATE FOR THE LONG RUN! HOW THIS IS DONE IS DESCRIBED IN THE NEXT ANSWER.

Ok, I've got my server installed and not want to create a real SSL server Certificate for it. How do I do it? [L]

Real SSL Server Certificate를 생성하기 위한 과정은 다음과 같다:

1. SSLeay를 시스템에 설치하고 PATH 환경변수에 SSLeay의 경로를 설정한다.

2. 다음의 명령으로 Apache 서버에 대한 RSA 개인키를 생성한다(이 개인키는 3중DES로 암호화되어 PEM 포맷으로 변환되어진다):

$ ssleay genrsa -des3 -out server.key 1024

생성하는 과정에서 PEM Pass Phrase를 입력하게 되는데, 이 pass phrase는 잃어버리지 않도록 잘 기록해 두어야 하며, 이 결과로 얻어지는 server.key파일은 이후의 복구를 위하여 안전한 곳에 백업해 둔다. 다음의 명령어로 이 RSA 개인키의 자세한 내용을 볼 수 있다:

$ ssleay rsa -noout -text -in server.key

다음의 명령으로 decrypted PEM 버전의 RSA 개인키를 생성할 수도 있다(권장되지 않는다):

$ ssleay rsa -in server.key -out server.key.unsecure

3. RSA 개인키에 대한 Certificate Signing Request (CSR)을 생성한다(PEM 포맷으로 생성된다):

$ ssleay req -new -days 365 -key server.key -out server.csr

다음의 명령으로 이 CSR의 자세한 내용을 볼 수 있다.

$ ssleay req -noout -text -in server.csr

4. 생성된 CSR을 CA에게 보내어 CA의 서명을 받음으로써 Apache에 실재로 사용할 수 있는 증명서를 받는다. 이 때 CSR에 서명할 CA의 선택에는 두가지의 옵션이 있다:

첫번째는 Verisign이나 Thawte와 같은 상용 CA에게 CSR 서명을 받는 것으로서, 이경우에는 보통 해당 CA의 홈페이지에서 CSR을 입력한 후 요금을 지불하고 서명된 증명서를 받아서 server.crt 파일에 저장하면 된다. 각 상용 CA들의 자세한 정보는 다음의 사이트들을 참조한다:

Verisign http://digitalid.verisign.com/server/apacheNotice.htm

Thawte Consulting http://www.thawte.com/certs/server/request.html

CertiSign Certificadora Digital Ltda. http://www.certisign.com.br

IKS GmbH http://www.iks-jena.de/produkte/ca/

Uptime Commerce Ltd. http://www.uptimecommerce.com

BelSign NV/SA http://www.belsign.be

두번째 방법은 self-signed CA를 사용하는 것이며, 이 경우 CSR을 자신이 만든 CA로 서명하게 된다. 다음 질문에서 자신의 CA로 CSR을 서명하는 방법에 대하여 설명할 것이다.

다음의 명령으로 발급된 증명서의 자세한 내용을 볼 수 있다:

$ ssleay x509 -noout -text -in server.crt

5. 위의 과정을 통하여 얻은 두개의 파일 server.key와 server.crt의 위치를 httpd.conf 파일에서 각각 다음과 같이 지정해 준다:

SSLCertificateFile /path/to/this/server.crt

SSLCertificateKeyFile /path/to/this/server.key

server.csr 파일은 더 이상 필요하지 않다.

How can I create and use my own Certificate Authority (CA)? [L]

SSLeay가 제공하는 CA.sh 스크립트를 가지고 Self-signed CA를 생성하고 사용할 수 있으며, 이 스크립트를 이용하는 방법은 다음과 같다:

1. 다음의 명령으로 자신의 CA에 대한 RSA 개인키를 생성한다(이 개인키는 3중DES로 암호화되어 PEM 포맷으로 변환되어진다):

$ ssleay genrsa -des3 -out ca.key 1024

생성하는 과정에서 PEM Pass Phrase를 입력하게 되는데, 이 pass phrase는 잃어버리지 않도록 잘 기록해 두어야 하며, 이 결과로 얻어지는 server.key파일은 이후의 복구를 위하여 안전한 곳에 백업해 둔다. 다음의 명령어로 이 RSA 개인키의 자세한 내용을 볼 수 있다:

$ ssleay rsa -noout -text -in ca.key

다음의 명령으로 decrypted PEM 버전의 RSA 개인키를 생성할 수도 있다(권장되지 않는다):

$ ssleay rsa -in ca.key -out ca.key.unsecure

2. 이 CA의 RSA 키에 대한 self-signed CA 증명서(X.509 structure)를 생성한다(PEM 포맷으로 생성된다):

$ ssleay req -new -x509 -days 365 -key ca.key -out ca.crt

다음의 명령으로 생성된 증명서의 자세한 내용을 볼 수 있다:

$ ssleay x509 -noout -text -in ca.crt

3. 서명 작업을 위한 스크립트를 준비한다. “ssleay ca”라는 명령어는 몇몇 까다로운 요구사항을 필요로 하며, 또한 SSLeay의 기본 설정에서는 사용자가 직접 “ssleay ca” 명령을 실행하는 것을 허용하지 않기 때문에 서명을 위한 스크립트가 필요하다. Mod_ssl은 sign.sh라는 이름의 서명을 위한 스크립트를 제공하며(pkg.contrib 디렉토리에 위치) 이 스크립트를 사용하기를 권장한다.

4. 다음의 명령으로 Apache 서버의 SSL 증명서를 생성하기 위한 CSR에 서명한다:

$ ./sign.sh server.csr

CSR에 서명함으로써 server.crt 파일을 얻게 되며, 이 server.crt를 Apache의 증명서로 사용하게 된다.

How can I change the pass-phrase on my private key file? [L]

다음의 명령어를 이용하여 개인키를 이전 pass-phrase를 가지고 읽은 후 새로운 pass-phrase로 다시 덮어쓴다:

$ ssleay rsa -des3 -in server.key -out server.key.new

$ mv server.key.new server.key

이 과정에서 두번의 PEM pass-phrase를 요구하게 되는데, 첫번째에는 이전의 pass-phrase를 입력하고 두번째는 새로운 pass-phrase를 입력한다.

How can I get rid of the pass-phrase dialog at Apache startup time? [L]

Server.key 파일에 저장되어 있는 RSA 개인키는 보안 상의 이유로 암호화되어져 저장되어져 있기 때문에 Apache를 시작하거나 재시동할 때마다 pass-phrase를 입력 받기 위한 dialog가 실행되게 된다. 만약 이 서버가 충분히 안전하다고 확신할 수 있는 경우 dialog를 없앨 수 있다. 과정은 다음과 같다.

1. RSA 개인키로부터 암호화를 제거한다(원본 파일은 남겨둔다):

$ cp server.key server.key.org

$ ssleay rsa -in server.key.org -out server.key

2. server.key 파일을 루트만이 읽을 수 있도록 해준다.:

$ chmod 400 server.key

이 과정을 거쳐 server.key는 암호화되지 않은 키를 가지게 되며, 이 key 파일을 Apache에 설치해 준 경우 더 이상 pass-phrase를 요구하지 않게 된다. 그러나 이것은 보안상 상당한 위험을 가진다. 따라서 항상 파일의 접근 권한을 루트나 웹 서버 사용자만이 그 파일에 접근할 수 있도록 설정해야 한다.

How do I verify that a private key matches its Certificate? [L]

개인키는 일련의 숫자들을 가지는데, 이 수들 중 2개는 공개키에 포함되며, 나머지는 개인키의 일부분이 된다. 공개키에 사용된 bit들은 증명서에 포함되며 이 숫자들은 CSR로부터 얻을 수 있다. 증명서의 공개키가 개인키의 public portin과 일치하는가를 확인하기 위해서 증명서 파일과 개인키 파일을 다음의 명령으로 비교한다:

$ ssleay x509 -noout -text -in server.crt

$ ssleay rsa -noout -text -in server.key

이 때 키와 증명서 안의 ‘modulus’와 ‘public exponent’ 부분이 서로 일치해야 한다. 그러나 public exponent는 보통 65537이며 긴 modulus를 비교하는 것이 힘들기 때문에 다음과 같은 명령을 사용할 수 있다:

$ ssleay x509 -noout -modulus -in server.crt | ssleay md5

$ ssleay rsa -noout -modulus -in server.key | ssleay md5

이 명령은 매우 짧은 숫자들을 보여주며, 이 숫자들을 비교하면 된다. 만약 공개키와 개인키가 다르다면 이 숫자들이 다를 것이다. 특정 CSR이 어느 키나 증명서에 대한 것인가를 알고자 할 때는 다음과 같은 명령을 사용한다:

$ ssleay req -noout -modulus -in server.csr | ssleay md5

Why does my 2048-bit private key not work? [L]

SSL은 웹 브라우져들과의 호환성을 위하여 기본 키 길이로 512 bit와 1024 bit를 사용한다. 1024 bit 이상의 키 길이는 일부 버전의 Netscape Navigator와 MSIE, 그리고 RSA사의 BSAFE 암호화 ToolKit을 사용하는 일부 브라우져들과 호환되지 않기 때문에 1024 bit의 길이를 가지는 키를 사용하는 것이 권장된다.

Why is client authentication broken after upgrading from SSLeay version 0.8 to 0.9? [L]

SSLCACertificatePath directive에 지정한 경로에서 CA 증명서를 찾을 때 SSLeay는 hash symlink를 통해서 증명서를 찾게 되며, 이 hash 값은 “ssleay x509 ?noout ?hash” 명령으로 생성된다. 그런데 SSLeay 0.8에서 0.9로 오면서 증명서에 대한 hash를 계산하는데 사용되는 알고리즘이 변경되었다. 따라서 SSLeay를 업그레이드한 후 먼저 모든 예전 hash symlink를 삭제하고 새로운 hash symlink를 생성해야 한다.

　

About SSL Protocol

Why has my webserver a higher load now that I run SSL there? [L]

SSL은 강력한 암호화를 사용하며, 또한 HTTPS를 통하여 어떤 웹 페이지를 요청하는 경우 심지어 그 페이지 내의 이미지들까지 암호화된 채로 전송되기 때문에 HTTPS 전송량이 많은 경우 일반적인 Apache 서버에 비해 더 많은 서버 로드가 증가한다.

What SSL Ciphers are supported by mod_ssl? [L]

설치된 SSLeay가 지원하는 거의 대부분의 SSL cipher를 지원하며, 특히 최소한 다음과 같은 cipher들을 지원한다:

RC4 with MD5

RC4 with MD5 (export version restricted to 40-bit key)

RC2 with MD5

RC2 with MD5 (export version restricted to 40-bit key)

IDEA with MD5

DES with MD5

Triple-DES with MD5

다음의 명령으로 실제로 지원하는 cipher들의 목록을 볼 수 있다:

$ ssleay ciphers -v

Why can't I use SSL with name-based/non-IP-based virtual hosts? [L]

이 문제는 닭과 달걀의 문제와 같다. SSL 프로토콜 레이어는 HTTP 프로토콜 레이어의 아래에 위치하여 HTTP를 encapsulate한다. SSL 연결(HTTPS)이 이루어질 때 Apache/mod_ssl은 클라이언트와 SSL 프로토콜 파라미터들을 협상해야 하며, 이를 위해 mod_ssl은 그 가상서버(virtual server)의 설정(예를 들어 cipher suite나 server certificate 등)을 참조해야 한다. 그러나 올바른 virtual server를 찾기 위해 Apache는 Host HTTP heaer field를 알아야 하며, 이를 위해 HTTP request header가 읽혀져야 한다. 이 과정은 SSL handshake가 끝나기 전에는 수행되지 않는데 이 과정이 수행되어야 얻어지는 정보를 이미 SSL handshake 단계가 요구하였기 때문에 이러한 문제가 발생하게 된다.

When I use Basic Authentication over HTTPS the lock icon in Netscape browsers still show the unlocked state when the dialog pops up. Does this mean the username/password is still transmitted unencrypted? [L]

아니다, username과 passwd는 이미 암호화되어 전송되어진 것이다. Netscape 브라우져의 자물쇠 아이콘은 SSL/TLS 레이어와 정확히 동기화되지 않으며, 즉 해당 웹 페이지의 첫번째 데이터가 전송되는 시점에서야 잠김 표시로 전환되는 것이다. Basic Authentication은 HTTP 레이어의 기능이며 HTTP 레이어는 SSL/TLS 레이어 위에 위치한다. 따라서 HTTPS 프로토콜에서 어떠한 HTTP 데이터의 통신이 이루어지기 위해서는 반드시 그 이전에 SSL/TLS 레이어가 handshake 단계를 수행하고 암호화된 통신으로 전환되어야만 한다. 따라서 인증 단계에서 자물쇠 아이콘이 잠김 상태가 아니더라도 username과 passwd는 이미 암호화된 상태로 전송되게 된다.