1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
|
<html>
<head>
<title>mod_ssl: Introduction</title>
<!--
Copyright (c) 1998-2001 Ralf S. Engelschall. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above
copyright notice, this list of conditions and the following
disclaimer.
2. Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials
provided with the distribution.
3. All advertising materials mentioning features or use of this
software must display the following acknowledgment:
"This product includes software developed by
Ralf S. Engelschall <rse@engelschall.com> for use in the
mod_ssl project (http://www.modssl.org/)."
4. The name "mod_ssl" must not be used to endorse or promote
products derived from this software without prior written
permission.
5. Redistributions of any form whatsoever must retain the
following acknowledgment:
"This product includes software developed by
Ralf S. Engelschall <rse@engelschall.com> for use in the
mod_ssl project (http://www.modssl.org/)."
THIS SOFTWARE IS PROVIDED BY RALF S. ENGELSCHALL ``AS IS'' AND ANY
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL RALF S. ENGELSCHALL OR
HIS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
OF THE POSSIBILITY OF SUCH DAMAGE.
-->
<style type="text/css"><!--
A:link {
text-decoration: none;
color: #6666cc;
}
A:active {
text-decoration: none;
color: #6666cc;
}
A:visited {
text-decoration: none;
color: #6666cc;
}
#sf {
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
H1 {
font-weight: bold;
font-size: 24pt;
line-height: 24pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
H2 {
font-weight: bold;
font-size: 18pt;
line-height: 18pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
H3 {
font-weight: bold;
font-size: 14pt;
line-height: 14pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
H4 {
font-weight: bold;
font-size: 12pt;
line-height: 12pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
#H {
}
#D {
background-color: #f0f0f0;
}
#faq {
font-weight: bold;
font-size: 16pt;
line-height: 16pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
#howto {
font-weight: bold;
font-size: 16pt;
line-height: 16pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
#term {
font-weight: bold;
font-size: 16pt;
line-height: 16pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
--></style>
<script type="text/javascript" language="JavaScript">
<!-- Hiding the code
function ro_imgNormal(imgName) {
if (document.images) {
document[imgName].src = eval(imgName + '_n.src');
self.status = '';
}
}
function ro_imgOver(imgName, descript) {
if (document.images) {
document[imgName].src = eval(imgName + '_o.src');
self.status = descript;
}
}
// done hiding -->
</script>
<script type="text/javascript" language="JavaScript">
<!-- Hiding the code
if (document.images) {
ro_img_prev_top_n = new Image();
ro_img_prev_top_n.src = 'ssl_template.navbut-prev-n.gif';
ro_img_prev_top_o = new Image();
ro_img_prev_top_o.src = 'ssl_template.navbut-prev-s.gif';
}
// done hiding -->
</script>
<script type="text/javascript" language="JavaScript">
<!-- Hiding the code
if (document.images) {
ro_img_prev_bot_n = new Image();
ro_img_prev_bot_n.src = 'ssl_template.navbut-prev-n.gif';
ro_img_prev_bot_o = new Image();
ro_img_prev_bot_o.src = 'ssl_template.navbut-prev-s.gif';
}
// done hiding -->
</script>
<script type="text/javascript" language="JavaScript">
<!-- Hiding the code
if (document.images) {
ro_img_next_top_n = new Image();
ro_img_next_top_n.src = 'ssl_template.navbut-next-n.gif';
ro_img_next_top_o = new Image();
ro_img_next_top_o.src = 'ssl_template.navbut-next-s.gif';
}
// done hiding -->
</script>
<script type="text/javascript" language="JavaScript">
<!-- Hiding the code
if (document.images) {
ro_img_next_bot_n = new Image();
ro_img_next_bot_n.src = 'ssl_template.navbut-next-n.gif';
ro_img_next_bot_o = new Image();
ro_img_next_bot_o.src = 'ssl_template.navbut-next-s.gif';
}
// done hiding -->
</script>
</head>
<body bgcolor="#ffffff" text="#000000" link="#333399" alink="#9999ff" vlink="#000066">
<div align="center">
<table width="600" cellspacing="0" cellpadding="0" border="0" summary="">
<tr>
<td>
<img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="600" height="1" align="bottom" border="0"><br>
<table width="600" cellspacing="0" cellpadding="0" summary="">
<tr>
<td>
<table width="600" summary="">
<tr>
<td align="left" valign="bottom">
<font face="Arial,Helvetica" size="+2"><b>mod_ssl</b></font>
</td>
<td align="right">
<img src="ssl_template.head-chapter.gif" alt="Chapter" width="175" height="94"> <img src="ssl_template.head-num-2.gif" alt="2" width="74" height="89">
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td><img src="ssl_template.imgdot-1x1-000000.gif" alt="" width="600" height="2" align="bottom" border="0"></td>
</tr>
<tr>
<td>
<table width="600" border="0" summary="">
<tr>
<td valign="top" align="left" width="250">
<a href="ssl_overview.html" onmouseover="ro_imgOver('ro_img_prev_top', 'previous page'); return true" onmouseout="ro_imgNormal('ro_img_prev_top'); return true" onfocus="ro_imgOver('ro_img_prev_top', 'previous page'); return true" onblur="ro_imgNormal('ro_img_prev_top'); return true"><img name="ro_img_prev_top" src="ssl_template.navbut-prev-n.gif" alt="previous page" width="70" height="18" border="0"></a><br><font color="#000000">Overview</font>
</td>
<td valign="top" align="right" width="250">
<a href="ssl_reference.html" onmouseover="ro_imgOver('ro_img_next_top', 'next page'); return true" onmouseout="ro_imgNormal('ro_img_next_top'); return true" onfocus="ro_imgOver('ro_img_next_top', 'next page'); return true" onblur="ro_imgNormal('ro_img_next_top'); return true"><img name="ro_img_next_top" src="ssl_template.navbut-next-n.gif" alt="next page" width="70" height="18" border="0"></a><br><font color="#000000">Reference</font>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td>
<br>
<img src="ssl_template.title-intro.gif" alt="Introduction" width="456" height="60">
</td>
</tr>
</table>
<div align="right">
<table cellspacing="0" cellpadding="0" width="400" summary="">
<tr>
<td>
<em>
``The nice thing about standards is that there are so many to choose from.
And if you really don't like all the standards you just have to wait another
year until the one arises you are looking for.''
</em>
</td>
</tr>
<tr>
<td align="right">
<font size="-1">
A. Tanenbaum, ``Introduction to Computer Networks''
</font>
</td>
</tr>
</table>
</div>
<p>
<table cellspacing="0" cellpadding="0" border="0" summary="">
<tr valign="bottom">
<td>
<img src="ssl_intro.gfont000.gif" alt="A" width="37" height="35" border="0" align="left">
s an introduction this chapter is aimed at readers who are familiar
with the Web, HTTP, and Apache, but are not security experts. It is not
intended to be a definitive guide to the SSL protocol, nor does it discuss
specific techniques for managing certificates in an organization, or the
important legal issues of patents and import and export restrictions. Rather,
it is intended to provide a common background to mod_ssl users by pulling
together various concepts, definitions, and examples as a starting point for
further exploration.
<p>
The presented content is mainly derived, with permission by the author, from
the article <a
href="http://www.ultranet.com/~fhirsch/Papers/wwwj/index.html"><em>Introducing SSL
and Certificates using SSLeay</em></a> from <a
href="http://www.ultranet.com/~fhirsch/">Frederick J. Hirsch</a>, of The Open
Group Research Institute, which was published in <a
href="http://www.ora.com/catalog/wjsum97/"><em>Web Security: A Matter of
Trust</em></a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997.
Please send any postive feedback to <a
href="mailto:fjh@alum.mit.edu">Frederick Hirsch</a> (the original
article author) and all negative feedback to <a
href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (the mod_ssl
author).
</td>
<td>
</td>
<td>
<div align="right">
<table cellspacing="0" cellpadding="5" border="0" bgcolor="#ccccff" summary="">
<tr>
<td bgcolor="#333399">
<font face="Arial,Helvetica" color="#ccccff">
<b>Table Of Contents</b>
</font>
</td>
</tr>
<tr>
<td>
<font face="Arial,Helvetica" size="-1">
<a href="#ToC1"><strong>Cryptographic Techniques</strong></a><br>
<a href="#ToC2"><strong>Cryptographic Algorithms</strong></a><br>
<a href="#ToC3"><strong>Message Digests</strong></a><br>
<a href="#ToC4"><strong>Digital Signatures</strong></a><br>
<a href="#ToC5"><strong>Certificates</strong></a><br>
<a href="#ToC6"><strong>Certificate Contents</strong></a><br>
<a href="#ToC7"><strong>Certificate Authorities</strong></a><br>
<a href="#ToC8"><strong>Certificate Chains</strong></a><br>
<a href="#ToC9"><strong>Creating a Root-Level CA</strong></a><br>
<a href="#ToC10"><strong>Certificate Management</strong></a><br>
<a href="#ToC11"><strong>Secure Sockets Layer (SSL)</strong></a><br>
<a href="#ToC12"><strong>Session Establishment</strong></a><br>
<a href="#ToC13"><strong>Key Exchange Method</strong></a><br>
<a href="#ToC14"><strong>Cipher for Data Transfer</strong></a><br>
<a href="#ToC15"><strong>Digest Function</strong></a><br>
<a href="#ToC16"><strong>Handshake Sequence Protocol</strong></a><br>
<a href="#ToC17"><strong>Data Transfer</strong></a><br>
<a href="#ToC18"><strong>Securing HTTP Communication</strong></a><br>
<a href="#ToC19"><strong>References</strong></a><br>
</font>
</td>
</tr>
</table>
</div>
</td>
</tr>
</table>
<h2><a name="ToC1">Cryptographic Techniques</a></h2>
Understanding SSL requires an understanding of cryptographic algorithms,
message digest functions (aka. one-way or hash functions), and digital
signatures. These techniques are the subject of entire books (see for instance
[<a href="#AC96">AC96</a>]) and provide the basis for privacy, integrity, and
authentication.
<h3><a name="ToC2">Cryptographic Algorithms</a></h3>
Suppose Alice wants to send a message to her bank to transfer some money.
Alice would like the message to be private, since it will include information
such as her account number and transfer amount. One solution is to use a
cryptographic algorithm, a technique that would transform her message into an
encrypted form, unreadable except by those it is intended for. Once in this
form, the message may only be interpreted through the use of a secret key.
Without the key the message is useless: good cryptographic algorithms make it
so difficult for intruders to decode the original text that it isn't worth
their effort.
<p>
There are two categories of cryptographic algorithms:
conventional and public key.
<ul>
<li><em>Conventional cryptography</em>, also known as symmetric
cryptography, requires the sender and receiver to share a key: a secret
piece of information that may be used to encrypt or decrypt a message.
If this key is secret, then nobody other than the sender or receiver may
read the message. If Alice and the bank know a secret key, then they
may send each other private messages. The task of privately choosing a key
before communicating, however, can be problematic.
<p>
<li><em>Public key cryptography</em>, also known as asymmetric cryptography,
solves the key exchange problem by defining an algorithm which uses two keys,
each of which may be used to encrypt a message. If one key is used to encrypt
a message then the other must be used to decrypt it. This makes it possible
to receive secure messages by simply publishing one key (the public key) and
keeping the other secret (the private key).
<p>
Anyone may encrypt a message using the public key, but only the owner of the
private key will be able to read it. In this way, Alice may send private
messages to the owner of a key-pair (the bank), by encrypting it using their
public key. Only the bank will be able to decrypt it.
</ul>
<h3><a name="ToC3">Message Digests</a></h3>
Although Alice may encrypt her message to make it private, there is still a
concern that someone might modify her original message or substitute
it with a different one, in order to transfer the money to themselves, for
instance. One way of guaranteeing the integrity of Alice's message is to
create a concise summary of her message and send this to the bank as well.
Upon receipt of the message, the bank creates its own summary and compares it
with the one Alice sent. If they agree then the message was received intact.
<p>
A summary such as this is called a <em>message digest</em>, <em>one-way
function</em> or <em>hash function</em>. Message digests are used to create
short, fixed-length representations of longer, variable-length messages.
Digest algorithms are designed to produce unique digests for different
messages. Message digests are designed to make it too difficult to determine
the message from the digest, and also impossible to find two different
messages which create the same digest -- thus eliminating the possibility of
substituting one message for another while maintaining the same digest.
<p>
Another challenge that Alice faces is finding a way to send the digest to the
bank securely; when this is achieved, the integrity of the associated message
is assured. One way to to this is to include the digest in a digital
signature.
<h3><a name="ToC4">Digital Signatures</a></h3>
When Alice sends a message to the bank, the bank needs to ensure that the
message is really from her, so an intruder does not request a transaction
involving her account. A <em>digital signature</em>, created by Alice and
included with the message, serves this purpose.
<p>
Digital signatures are created by encrypting a digest of the message,
and other information (such as a sequence number) with the sender's
private key. Though anyone may <em>decrypt</em> the signature using the public
key, only the signer knows the private key. This means that only they may
have signed it. Including the digest in the signature means the signature is
only good for that message; it also ensures the integrity of the message since
no one can change the digest and still sign it.
<p>
To guard against interception and reuse of the signature by an intruder at a
later date, the signature contains a unique sequence number. This protects
the bank from a fraudulent claim from Alice that she did not send the message
-- only she could have signed it (non-repudiation).
<h2><a name="ToC5">Certificates</a></h2>
Although Alice could have sent a private message to the bank, signed it, and
ensured the integrity of the message, she still needs to be sure that she is
really communicating with the bank. This means that she needs to be sure that
the public key she is using corresponds to the bank's private key. Similarly,
the bank also needs to verify that the message signature really corresponds to
Alice's signature.
<p>
If each party has a certificate which validates the other's identity, confirms
the public key, and is signed by a trusted agency, then they both will be
assured that they are communicating with whom they think they are. Such a
trusted agency is called a <em>Certificate Authority</em>, and certificates are
used for authentication.
<h3><a name="ToC6">Certificate Contents</a></h3>
A certificate associates a public key with the real identity of an individual,
server, or other entity, known as the subject. As shown in <a
href="#table1">Table 1</a>, information about the subject includes identifying
information (the distinguished name), and the public key. It also includes
the identification and signature of the Certificate Authority that issued the
certificate, and the period of time during which the certificate is valid. It
may have additional information (or extensions) as well as administrative
information for the Certificate Authority's use, such as a serial number.
<p>
<div align="center">
<a name="table1"></a>
<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
<caption align="bottom" id="sf">Table 1: Certificate Information</caption>
<tr><td bgcolor="#cccccc">
<table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
<tr><td valign="top" align="center" bgcolor="#ffffff">
<table summary="">
<tr valign="top"><td><b>Subject:</b></td>
<td>Distinguished Name, Public Key</td></tr>
<tr valign="top"><td><b>Issuer:</b></td>
<td>Distinguished Name, Signature</td></tr>
<tr><td><b>Period of Validity:</b></td>
<td>Not Before Date, Not After Date</td></tr>
<tr><td><b>Administrative Information:</b></td>
<td>Version, Serial Number</td></TR>
<tr><td><b>Extended Information:</b></td>
<td>Basic Contraints, Netscape Flags, etc.</td></TR>
</table>
</td>
</tr></table>
</td></tr></table>
</div>
<p>
A distinguished name is used to provide an identity in a specific context --
for instance, an individual might have a personal certificate as well as one
for their identity as an employee. Distinguished names are defined by the
X.509 standard [<a href="#X509">X509</A>], which defines the fields, field
names, and abbreviations used to refer to the fields
(see <a href="#table2">Table 2</a>).
<p>
<div align="center">
<a name="table2"></a>
<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
<caption align="bottom" id="sf">Table 2: Distinguished Name Information</caption>
<tr><td bgcolor="#cccccc">
<table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
<tr><td valign="top" align="center" bgcolor="#ffffff">
<table summary="">
<tr valign="top"><td><b>DN Field:</b></td><td><b>Abbrev.:</b></td><td><b>Description:</b></td>
<td><b>Example:</b></td>
</t>
<tr valign="top"><td>Common Name</td><td>CN</td>
<td>Name being certified</td><td>CN=Joe Average</td></tr>
<tr valign="top"><td>Organization or Company</td><td>O</td>
<td>Name is associated with this<br>organization</td><td>O=Snake Oil, Ltd.</td></tr>
<tr valign="top"><td>Organizational Unit</td><td>OU</td>
<td>Name is associated with this <br>organization unit, such as a department</td><td>OU=Research Institute</td></tr>
<tr valign="top"><td>City/Locality</td><td>L</td>
<td>Name is located in this City</td><td>L=Snake City</td></tr>
<tr valign="top"><td>State/Province</td><td>ST</td>
<td>Name is located in this State/Province</td><td>ST=Desert</td></tr>
<tr valign="top"><td>Country</td><td>C</td>
<td>Name is located in this Country (ISO code)</td><td>C=XZ</td></tr>
</table>
</td>
</tr></table>
</td></tr></table>
</div>
<p>
A Certificate Authority may define a policy specifying which distinguished
field names are optional, and which are required. It may also place
requirements upon the field contents, as may users of certificates. As an
example, a Netscape browser requires that the Common Name for a certificate
representing a server has a name which matches a wildcard pattern for the
domain name of that server, such as <code>*.snakeoil.com</code>.
<p>
The binary format of a certificate is defined using the ASN.1 notation [ <a
href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>]. This notation defines how to
specify the contents, and encoding rules define how this information is
translated into binary form. The binary encoding of the certificate is
defined using Distinguished Encoding Rules (DER), which are based on the more
general Basic Encoding Rules (BER). For those transmissions which cannot
handle binary, the binary form may be translated into an ASCII form by using
Base64 encoding [<a href="#MIME">MIME</a>]. This encoded version is called PEM
encoded (the name comes from "Privacy Enhanced Mail"), when placed between
begin and end delimiter lines as illustrated in <a href="#table3">Table 3</a>.
<p>
<div align="center">
<a name="table3"></a>
<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
<caption align="bottom" id="sf">Table 3: Example of a PEM-encoded certificate (snakeoil.crt)</caption>
<tr><td bgcolor="#cccccc">
<table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
<tr><td valign="top" align="center" bgcolor="#ffffff">
<table cellspacing="0" cellpadding="0" summary=""><tr><td>
<div class="code"><pre>
-----BEGIN CERTIFICATE-----
MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
-----END CERTIFICATE-----</pre></div>
</td></tr></table>
</td>
</tr></table>
</td></tr></table>
</div>
<h3><a name="ToC7">Certificate Authorities</a></h3>
By first verifying the information in a certificate request before granting
the certificate, the Certificate Authority assures the identity of the private
key owner of a key-pair. For instance, if Alice requests a personal
certificate, the Certificate Authority must first make sure that Alice really
is the person the certificate request claims.
<h4><a name="ToC8">Certificate Chains</a></h4>
A Certificate Authority may also issue a certificate for another Certificate
Authority. When examining a certificate, Alice may need to examine the
certificate of the issuer, for each parent Certificate Authority, until
reaching one which she has confidence in. She may decide to trust only
certificates with a limited chain of issuers, to reduce her risk of a "bad"
certificate in the chain.
<h4><a name="ToC9">Creating a Root-Level CA</a></h4>
As noted earlier, each certificate requires an issuer to assert the validity
of the identity of the certificate subject, up to the top-level Certificate
Authority (CA). This presents a problem: Since this is who vouches for the
certificate of the top-level authority, which has no issuer?
In this unique case, the certificate is "self-signed", so the issuer of the
certificate is the same as the subject. As a result, one must exercise extra
care in trusting a self-signed certificate. The wide publication of a public
key by the root authority reduces the risk in trusting this key -- it would be
obvious if someone else publicized a key claiming to be the authority.
Browsers are preconfigured to trust well-known certificate authorities.
<p>
A number of companies, such as <a href="http://www.thawte.com/">Thawte</a> and
<a href="http://www.verisign.com/">VeriSign</a> have established themselves as
Certificate Authorities. These companies provide the following services:
<ul>
<li>Verifying certificate requests
<li>Processing certificate requests
<li>Issuing and managing certificates
</ul>
<p>
It is also possible to create your own Certificate Authority. Although risky
in the Internet environment, it may be useful within an Intranet where the
organization can easily verify the identities of individuals and servers.
<h4><a name="ToC10">Certificate Management</a></h4>
Establishing a Certificate Authority is a responsibility which requires a
solid administrative, technical, and management framework.
Certificate Authorities not only issue certificates, they also manage them --
that is, they determine how long certificates are valid, they renew them, and
they keep lists of certificates that have already been issued but are no
longer valid (Certificate Revocation Lists, or CRLs).
Say Alice is entitled to a certificate as an employee of a company. Say too,
that the certificate needs to be revoked when Alice leaves the company. Since
certificates are objects that get passed around, it is impossible to tell from
the certificate alone that it has been revoked.
When examining certificates for validity, therefore, it is necessary to
contact the issuing Certificate Authority to check CRLs -- this is not usually
an automated part of the process.
<p>
<div align="center"><B>Note:</B></div>
If you use a Certificate Authority that is not configured into browsers by
default, it is necessary to load the Certificate Authority certificate into
the browser, enabling the browser to validate server certificates signed by
that Certificate Authority. Doing so may be dangerous, since once loaded, the
browser will accept all certificates signed by that Certificate Authority.
<h2><a name="ToC11">Secure Sockets Layer (SSL)</a></h2>
The Secure Sockets Layer protocol is a protocol layer which may be placed
between a reliable connection-oriented network layer protocol (e.g. TCP/IP)
and the application protocol layer (e.g. HTTP). SSL provides for secure
communication between client and server by allowing mutual authentication, the
use of digital signatures for integrity, and encryption for privacy.
<p>
The protocol is designed to support a range of choices for specific algorithms
used for cryptography, digests, and signatures. This allows algorithm
selection for specific servers to be made based on legal, export or other
concerns, and also enables the protocol to take advantage of new algorithms.
Choices are negotiated between client and server at the start of establishing
a protocol session.
<p>
<div align="center">
<a name="table4"></a>
<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
<caption align="bottom" id="sf">Table 4: Versions of the SSL protocol</caption>
<tr><td bgcolor="#cccccc">
<table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
<tr><td valign="top" align="center" bgcolor="#ffffff">
<table summary="">
<tr valign="top">
<td><b>Version:</b></td>
<td><b>Source:</b></td>
<td><b>Description:</b></td>
<td><b>Browser Support:</b></td>
</tr>
<tr valign="top">
<td>SSL v2.0</td>
<td>Vendor Standard (from Netscape Corp.) [<a href="#SSL2">SSL2</a>]</td>
<td>First SSL protocol for which implementations exists</td>
<td>- NS Navigator 1.x/2.x<br>
- MS IE 3.x<br>
- Lynx/2.8+OpenSSL
</td>
</tr>
<tr valign="top">
<td>SSL v3.0</td>
<td>Expired Internet Draft (from Netscape Corp.) [<a href="#SSL3">SSL3</a>]</td>
<td>Revisions to prevent specific security attacks, add non-RSA ciphers, and support for certificate chains</td>
<td>- NS Navigator 2.x/3.x/4.x<br>
- MS IE 3.x/4.x<br>
- Lynx/2.8+OpenSSL
</td>
</tr>
<tr valign="top">
<td>TLS v1.0</td>
<td>Proposed Internet Standard (from IETF) [<a href="#TLS1">TLS1</a>]</td>
<td>Revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for
block ciphers, message order standardization and more alert messages.
</td>
<td>- Lynx/2.8+OpenSSL</td>
</table>
</td>
</tr></table>
</td></tr></table>
</div>
<p>
There are a number of versions of the SSL protocol, as shown in <a
href="#table4">Table 4</a>. As noted there, one of the benefits in SSL 3.0 is
that it adds support of certificate chain loading. This feature allows a
server to pass a server certificate along with issuer certificates to the
browser. Chain loading also permits the browser to validate the server
certificate, even if Certificate Authority certificates are not installed for
the intermediate issuers, since they are included in the certificate chain.
SSL 3.0 is the basis for the Transport Layer Security [<A
HREF="#TLS1">TLS</A>] protocol standard, currently in development by the
Internet Engineering Task Force (IETF).
<h3><a name="ToC12">Session Establishment</a></h3>
The SSL session is established by following a <I>handshake sequence</I>
between client and server, as shown in <a href="#figure1">Figure 1</a>. This
sequence may vary, depending on whether the server is configured to provide a
server certificate or request a client certificate. Though cases exist where
additional handshake steps are required for management of cipher information,
this article summarizes one common scenario: see the SSL specification for the
full range of possibilities.
<p>
<div align="center"><b>Note</b></div>
Once an SSL session has been established it may be reused, thus avoiding the
performance penalty of repeating the many steps needed to start a session.
For this the server assigns each SSL session a unique session identifier which
is cached in the server and which the client can use on forthcoming
connections to reduce the handshake (until the session identifer expires in
the cache of the server).
<p>
<div align="center">
<a name="figure1"></a>
<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
<caption align="bottom" id="sf">Figure 1: Simplified SSL Handshake Sequence</caption>
<tr><td bgcolor="#cccccc">
<table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
<tr><td valign="top" align="center" bgcolor="#ffffff">
<img src="ssl_intro_fig1.gif" alt="" width="423" height="327">
</td>
</tr></table>
</td></tr></table>
</div>
<p>
The elements of the handshake sequence, as used by the client and server, are
listed below:
<ol>
<li>Negotiate the Cipher Suite to be used during data transfer
<li>Establish and share a session key between client and server
<li>Optionally authenticate the server to the client
<li>Optionally authenticate the client to the server
</ol>
<p>
The first step, Cipher Suite Negotiation, allows the client and server to
choose a Cipher Suite supportable by both of them. The SSL3.0 protocol
specification defines 31 Cipher Suites. A Cipher Suite is defined by the
following components:
<ul>
<li>Key Exchange Method
<li>Cipher for Data Transfer
<li>Message Digest for creating the Message Authentication Code (MAC)
</ul>
These three elements are described in the sections that follow.
<h3><a name="ToC13">Key Exchange Method</a></h3>
The key exchange method defines how the shared secret symmetric cryptography
key used for application data transfer will be agreed upon by client and
server. SSL 2.0 uses RSA key exchange only, while SSL 3.0 supports a choice of
key exchange algorithms including the RSA key exchange when certificates are
used, and Diffie-Hellman key exchange for exchanging keys without certificates
and without prior communication between client and server.
<p>
One variable in the choice of key exchange methods is digital signatures --
whether or not to use them, and if so, what kind of signatures to use.
Signing with a private key provides assurance against a
man-in-the-middle-attack during the information exchange used in generating
the shared key [<a href="#AC96">AC96</a>, p516].
<h3><a name="ToC14">Cipher for Data Transfer</a></h3>
SSL uses the conventional cryptography algorithm (symmetric cryptography)
described earlier for encrypting messages in a session. There are nine
choices, including the choice to perform no encryption:
<ul>
<li>No encryption
<li>Stream Ciphers
<ul>
<li>RC4 with 40-bit keys
<li>RC4 with 128-bit keys
</ul>
<li>CBC Block Ciphers
<ul>
<li>RC2 with 40 bit key
<li>DES with 40 bit key
<li>DES with 56 bit key
<li>Triple-DES with 168 bit key
<li>Idea (128 bit key)
<li>Fortezza (96 bit key)
</ul>
</ul>
Here "CBC" refers to Cipher Block Chaining, which means that a portion of the
previously encrypted cipher text is used in the encryption of the current
block. "DES" refers to the Data Encryption Standard [<a href="#AC96">AC96</a>,
ch12], which has a number of variants (including DES40 and 3DES_EDE). "Idea"
is one of the best and cryptographically strongest available algorithms, and
"RC2" is a proprietary algorithm from RSA DSI [<a href="#AC96">AC96</a>,
ch13].
<h3><a name="ToC15">Digest Function</a></h3>
The choice of digest function determines how a digest is created from a record
unit. SSL supports the following:
<ul>
<li>No digest (Null choice)
<li>MD5, a 128-bit hash
<li>Secure Hash Algorithm (SHA-1), a 160-bit hash
</ul>
The message digest is used to create a Message Authentication Code (MAC) which
is encrypted with the message to provide integrity and to prevent against
replay attacks.
<h3><a name="ToC16">Handshake Sequence Protocol</a></h3>
The handshake sequence uses three protocols:
<ul>
<li>The <em>SSL Handshake Protocol</em>
for performing the client and server SSL session establishment.
<li>The <em>SSL Change Cipher Spec Protocol</em> for actually establishing agreement
on the Cipher Suite for the session.
<li>The <em>SSL Alert Protocol</em> for
conveying SSL error messages between client and server.
</ul>
These protocols, as well as application protocol data, are encapsulated in the
<em>SSL Record Protocol</em>, as shown in <a href="#figure2">Figure 2</a>. An
encapsulated protocol is transferred as data by the lower layer protocol,
which does not examine the data. The encapsulated protocol has no knowledge of
the underlying protocol.
<p>
<div align="center">
<a name="figure2"></a>
<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
<caption align="bottom" id="sf">Figure 2: SSL Protocol Stack</caption>
<tr><td bgcolor="#cccccc">
<table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
<tr><td valign="top" align="center" bgcolor="#ffffff">
<img src="ssl_intro_fig2.gif" alt="" width="428" height="217">
</td>
</tr></table>
</td></tr></table>
</div>
<p>
The encapsulation of SSL control protocols by the record protocol means that
if an active session is renegotiated the control protocols will be transmitted
securely. If there were no session before, then the Null cipher suite is
used, which means there is no encryption and messages have no integrity
digests until the session has been established.
<h3><a name="ToC17">Data Transfer</a></h3>
The SSL Record Protocol, shown in <a href="#figure3">Figure 3</a>, is used to
transfer application and SSL Control data between the client and server,
possibly fragmenting this data into smaller units, or combining multiple
higher level protocol data messages into single units. It may compress, attach
digest signatures, and encrypt these units before transmitting them using the
underlying reliable transport protocol (Note: currently all major SSL
implementations lack support for compression).
<p>
<div align="center">
<a name="figure3"></a>
<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
<caption align="bottom" id="sf">Figure 3: SSL Record Protocol</caption>
<tr><td bgcolor="#cccccc">
<table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
<tr><td valign="top" align="center" bgcolor="#ffffff">
<img src="ssl_intro_fig3.gif" alt="" width="423" height="323">
</td>
</tr></table>
</td></tr></table>
</div>
<h3><a name="ToC18">Securing HTTP Communication</a></h3>
One common use of SSL is to secure Web HTTP communication between a browser
and a webserver. This case does not preclude the use of non-secured HTTP. The
secure version is mainly plain HTTP over SSL (named HTTPS), but with one major
difference: it uses the URL scheme <code>https</code> rather than
<code>http</code> and a different server port (by default 443). This mainly
is what mod_ssl provides to you for the Apache webserver...
<h2><a name="ToC19">References</a></h2>
<ul>
<p>
<li><a name="AC96"></a>
[AC96] Bruce Schneier, <em>Applied Cryptography</em>, 2nd Edition, Wiley,
1996. See <a href="http://www.counterpane.com/">http://www.counterpane.com/</a> for
various other materials by Bruce Schneier.
<p>
<li><a name="X208"></a>
[X208] ITU-T Recommendation X.208, <em>Specification of Abstract Syntax Notation
One (ASN.1)</em>, 1988. See for instance <a
href="ftp://ftp.neda.com/pub/itu/x.series/x208.ps">
ftp://ftp.neda.com/pub/itu/x.series/x208.ps</a>.
<p>
<li><a name="X509"></a>
[X509] ITU-T Recommendation X.509, <em>The Directory - Authentication
Framework</em>, 1988. See for instance <a
href="ftp://ftp.bull.com/pub/OSIdirectory/ITUnov96/X.509/97x509final.doc">
ftp://ftp.bull.com/pub/OSIdirectory/ITUnov96/X.509/97x509final.doc</a>.
<p>
<li><a name="PKCS"></a>
[PKCS] Kaliski, Burton S., Jr., <em>An Overview of the PKCS Standards</em>, An RSA
Laboratories Technical Note, revised November 1, 1993.
See <a href="http://www.rsa.com/rsalabs/pubs/PKCS/">
http://www.rsa.com/rsalabs/pubs/PKCS/</a>.
<p>
<li><a name="MIME"></a>
[MIME] N. Freed, N. Borenstein, <em>Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies</em>, RFC2045.
See for instance <a href="ftp://ftp.isi.edu/in-notes/rfc2045.txt">
ftp://ftp.isi.edu/in-notes/rfc2045.txt</a>.
<p>
<li><a name="SSL2"></a>
[SSL2] Kipp E.B. Hickman, <em>The SSL Protocol</em>, 1995.
See <a href="http://www.netscape.com/eng/security/SSL_2.html">
http://www.netscape.com/eng/security/SSL_2.html</a>.
<p>
<li><a name="SSL3"></a>
[SSL3] Alan O. Freier, Philip Karlton, Paul C. Kocher, <em>The SSL Protocol
Version 3.0</em>, 1996. See <a
href="http://www.netscape.com/eng/ssl3/draft302.txt">
http://www.netscape.com/eng/ssl3/draft302.txt</a>.
<p>
<li><a name="TLS1"></a>
[TLS1] Tim Dierks, Christopher Allen, <em>The TLS Protocol Version 1.0</em>,
1997. See <a
href="ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-protocol-06.txt">
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-protocol-06.txt</a>.
</ul>
<p>
<br>
<table summary="">
<tr>
<td>
<table width="600" border="0" summary="">
<tr>
<td valign="top" align="left" width="250">
<a href="ssl_overview.html" onmouseover="ro_imgOver('ro_img_prev_bot', 'previous page'); return true" onmouseout="ro_imgNormal('ro_img_prev_bot'); return true" onfocus="ro_imgOver('ro_img_prev_bot', 'previous page'); return true" onblur="ro_imgNormal('ro_img_prev_bot'); return true"><img name="ro_img_prev_bot" src="ssl_template.navbut-prev-n.gif" alt="previous page" width="70" height="18" border="0"></a><br><font color="#000000">Overview</font>
</td>
<td valign="top" align="right" width="250">
<a href="ssl_reference.html" onmouseover="ro_imgOver('ro_img_next_bot', 'next page'); return true" onmouseout="ro_imgNormal('ro_img_next_bot'); return true" onfocus="ro_imgOver('ro_img_next_bot', 'next page'); return true" onblur="ro_imgNormal('ro_img_next_bot'); return true"><img name="ro_img_next_bot" src="ssl_template.navbut-next-n.gif" alt="next page" width="70" height="18" border="0"></a><br><font color="#000000">Reference</font>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td><img src="ssl_template.imgdot-1x1-000000.gif" alt="" width="600" height="2" align="bottom" border="0"></td>
</tr>
<tr>
<td><table width="598" summary="">
<tr>
<td align="left"><font face="Arial,Helvetica">
<a href="http://www.modssl.org/">mod_ssl</a> 2.8, User Manual<br>
The Apache Interface to OpenSSL
</font>
</td>
<td align="right"><font face="Arial,Helvetica">
Copyright © 1998-2001
<a href="http://www.engelschall.com/">Ralf S. Engelschall</a><br>
All Rights Reserved<br>
</font>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
</body>
</html>
|
