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
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
|
Kipp E.B. Hickman
Internet Draft Netscape Communications Corp
April 1995 (Expires 10/95)
The SSL Protocol
<draft-hickman-netscape-ssl-00.txt>
1. STATUS OF THIS MEMO
This document is an Internet-Draft.Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material or to
cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the "1id-
abstracts.txt" listing contained in the Internet- Drafts Shadow Directories
on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US
West Coast), or munnari.oz.au (Pacific Rim).
2. ABSTRACT
This document specifies the Secure Sockets Layer (SSL) protocol, a
security protocol that provides privacy over the Internet. The protocol
allows client/server applications to communicate in a way that cannot be
eavesdropped. Server's are always authenticated and clients are optionally
authenticated.
3. INTRODUCTION
The SSL Protocol is designed to provide privacy between two
communicating applications (a client and a server). Second, the protocol is
designed to authenticate the server, and optionally the client. SSL requires
a reliable transport protocol (e.g. TCP) for data transmission and
reception.
The advantage of the SSL Protocol is that it is application protocol
independent. A "higher level" application protocol (e.g. HTTP, FTP,
TELNET, etc.) can layer on top of the SSL Protocol transparently. The
SSL Protocol can negotiate an encryption algorithm and session key as
well as authenticate a server before the application protocol transmits or
receives its first byte of data. All of the application protocol data is
transmitted encrypted, ensuring privacy.
The SSL protocol provides "channel security" which has three basic
properties:
The channel is private. Encryption is used for all messages after a
simple handshake is used to define a secret key. Symmetric
cryptography is used for data encryption (e.g. DES, RC4, etc.)
The channel is authenticated. The server endpoint of the conversation
is always authenticated, while the client endpoint is optionally
authenticated. Asymmetric cryptography is used for authentication
Hickman [page 1]
(e.g. Public Key Cryptography).
The channel is reliable. The message transport includes a message
integrity check (using a MAC). Secure hash functions (e.g. MD2,
MD5) are used for MAC computations.
The SSL protocol is actually composed of two protocols. At the lowest
level, layered on top of some reliable transport protocol, is the "SSL
Record Protocol". The SSL Record Protocol is used for encapsulation of
all transmitted and received data, including the SSL Handshake Protocol,
which is used to establish security parameters.
4. SSL Record Protocol Specification
4.1 SSL Record Header Format
In SSL, all data sent is encapsulated in a record, an object which is
composed of a header and some non-zero amount of data. Each record
header contains a two or three byte length code. If the most significant bit
is set in the first byte of the record length code then the record has no
padding and the total header length will be 2 bytes, otherwise the record
has padding and the total header length will be 3 bytes. The record header
is transmitted before the data portion of the record.
Note that in the long header case (3 bytes total), the second most
significant bit in the first byte has special meaning. When zero, the record
being sent is a data record. When one, the record being sent is a security
escape (there are currently no examples of security escapes; this is
reserved for future versions of the protocol). In either case, the length code
describes how much data is in the record.
The record length code does not include the number of bytes consumed by
the record header (2 or 3). For the 2 byte header, the record length is
computed by (using a "C"-like notation):
RECORD-LENGTH = ((byte[0] & 0x7f) << 8)) | byte[1];
Where byte[0] represents the first byte received and byte[1] the second
byte received. When the 3 byte header is used, the record length is
computed as follows (using a "C"-like notation):
RECORD-LENGTH = ((byte[0] & 0x3f) << 8)) | byte[1];
IS-ESCAPE = (byte[0] & 0x40) != 0;
PADDING = byte[2];
The record header defines a value called PADDING. The PADDING
value specifies how many bytes of data were appended to the original
record by the sender. The padding data is used to make the record length
be a multiple of the block ciphers block size when a block cipher is used
for encryption.
The sender of a "padded" record appends the padding data to the end of its
normal data and then encrypts the total amount (which is now a multiple
of the block cipher's block size). The actual value of the padding data is
unimportant, but the encrypted form of it must be transmitted for the
receiver to properly decrypt the record. Once the total amount being
Hickman [page 2]
transmitted is known the header can be properly constructed with the
PADDING value set appropriately.
The receiver of a padded record decrypts the entire record data (sans
record length and the optional padding) to get the clear data, then subtracts
the PADDING value from the RECORD-LENGTH to determine the
final RECORD-LENGTH. The clear form of the padding data must be
discarded.
4.1.1 SSL Record Data Format
The data portion of an SSL record is composed of three components
(transmitted and received in the order shown):
MAC-DATA[MAC-SIZE]
ACTUAL-DATA[N]
PADDING-DATA[PADDING]
ACTUAL-DATA is the actual data being transmitted (the message
payload). PADDING-DATA is the padding data sent when a block cipher
is used and padding is needed. Finally, MAC-DATA is the "Message
Authentication Code".
When SSL records are sent in the clear, no cipher is used.Consequently the
amount of PADDING-DATA will be zero and the amount of MAC-
DATA will be zero. When encryption is in effect, the PADDING-DATA
will be a function of the cipher block size. The MAC-DATA is a function
of the CIPHER-CHOICE (more about that later).
The MAC-DATA is computed as follows:
MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA,
SEQUENCE-NUMBER ]
Where the SECRET data is fed to the hash function first, followed by the
ACTUAL-DATA, which is followed by the PADDING-DATA which is
finally followed by the SEQUENCE-NUMBER. The SEQUENCE-
NUMBER is a 32 bit value which is presented to the hash function as four
bytes, with the first byte being the most significant byte of the sequence
number, the second byte being the next most significant byte of the
sequence number, the third byte being the third most significant byte, and
the fourth byte being the least significant byte (that is, in network byte
order or "big endian" order).
MAC-SIZE is a function of the digest algorithm being used. For MD2 and
MD5 the MAC-SIZE will be 16 bytes (128 bits).
The SECRET value is a function of which party is sending the message. If
the client is sending the message then the SECRET is the CLIENT-
WRITE-KEY (the server will use the SERVER-READ-KEY to verify
the MAC). If the client is receiving the message then the SECRET is the
CLIENT-READ-KEY (the server will use the SERVER-WRITE-KEY
to
generate the MAC).
Hickman [page 3]
The SEQUENCE-NUMBER is a counter which is incremented by both
the sender and the receiver. For each transmission direction, a pair of
counters is kept (one by the sender, one by the receiver). Every time a
message is sent by a sender the counter is incremented. Sequence numbers
are 32 bit unsigned quantities and must wrap to zero after incrementing
past 0xFFFFFFFF.
The receiver of a message uses the expected value of the sequence number
as input into the MAC HASH function (the HASH function is chosen from
the CIPHER-CHOICE). The computed MAC-DATA must agree bit for
bit with the transmitted MAC-DATA. If the comparison is not identity
then the record is considered damaged, and it is to be treated as if an "I/O
Error" had occurred (i.e. an unrecoverable error is asserted and the
connection is closed).
A final consistency check is done when a block cipher is used and the
protocol is using encryption. The amount of data present in a record
(RECORD-LENGTH))must be a multiple of the cipher's block size. If
the received record is not a multiple of the cipher's block size then the
record is considered damaged, and it is to be treated as if an "I/O Error"
had occurred (i.e. an unrecoverable error is asserted and the connection is
closed).
The SSL Record Layer is used for all SSL communications, including
handshake messages, security escapes and application data transfers. The
SSL Record Layer is used by both the client and the server at all times.
For a two byte header, the maximum record length is 32767 bytes. For the
three byte header, the maximum record length is 16383 bytes. The SSL
Handshake Protocol messages are constrained to fit in a single SSL Record
Protocol record. Application protocol messages are allowed to consume
multiple SSL Record Protocol record's.
Before the first record is sent using SSL all sequence numbers are
initialized to zero. The transmit sequence number is incremented after
every message sent, starting with the CLIENT-HELLO and SERVER-
HELLO messages.
5. SSL Handshake Protocol Specification
5.1 SSL Handshake Protocol Flow
The SSL Handshake Protocol is used to negotiate security enhancements
to data sent using the SSL Record Protocol. The security enhancements
consist of authentication, symmetric encryption, and message integrity.
The SSL Handshake Protocol has two major phases. The first phase is
used to establish private communications. The second phase is used for
client authentication.
5.1.1 Phase 1
The first phase is the initial connection phase where both parties
communicate their "hello" messages. The client initiates the conversation
by sending the CLIENT-HELLO message. The server receives the
Hickman [page 4]
CLIENT-HELLO message and processes it responding with the
SERVER-HELLO message.
At this point both the client and server have enough information to know
whether or not a new "master key" is needed (The master key is used for
production of the symmetric encryption session keys). When a new master
key is not needed, both the client and the server proceed immediately to
phase 2.
When a new master key is needed, the SERVER-HELLO message will
contain enough information for the client to generate it. This includes the
server's signed certificate (more about that later), a list of bulk cipher
specifications (see below), and a connection-id (a connection-id is a
randomly generated value generated by the server that is used by the client
and server during a single connection). The client generates the master key
and responds with a CLIENT-MASTER-KEY message (or an ERROR
message if the server information indicates that the client and server
cannot agree on a bulk cipher).
It should be noted here that each SSL endpoint uses a pair of ciphers per
connection (for a total of four ciphers). At each endpoint, one cipher is
used for outgoing communications, and one is used for incoming
communications. When the client or server generate a session key, they
actually generate two keys, the SERVER-READ-KEY (also known as the
CLIENT-WRITE-KEY) and the SERVER-WRITE-KEY (also known
as the CLIENT-READ-KEY). The master key is used by the client and
server to generate the various session keys (more about that later).
Finally, the server sends a SERVER-VERIFY message to the client after
the master key has been determined. This final step authenticates the
server, because only a server which has the appropriate public key can
know the master key.
5.1.2 Phase 2
The second phase is the client authentication phase. The server has already
been authenticated by the client in the first phase, so this phase is primarily
used to authenticate the client. In a typical scenario, the server will require
authentication of the client and send a REQUEST-CERTIFICATE
message. The client will answer in the positive if it has the needed
information, or send an ERROR message if it does not. This protocol
specification does not define the semantics of an ERROR response to a
server request (e.g., an implementation can ignore the error, close the
connection, etc. and still conform to this specification). In addition, it is
permissable for a server to cache client authentication information with the
"session-id" cache. The server is not required to re-authenticate the client
on every connection.
When a party is done authenticating the other party, it sends its finished
message. For the client, the CLIENT-FINISHED message contains the
encrypted form of the CONNECTION-ID for the server to verify. If the
verification fails, the server sends an ERROR message.
Once a party has sent its finished message it must continue to listen to its
peers messages until it too receives a finished message. Once a party has
Hickman [page 5]
both sent a finished message and received its peers finished message, the
SSL handshake protocol is done. At this point the application protocol
begins to operate (Note: the application protocol continues to be layered
on the SSL Record Protocol).
5.2 Typical Protocol Message Flow
The following sequences define several typical protocol message flows for
the SSL Handshake Protocol. In these examples we have two principals in
the conversation: the client and the server. We use a notation commonly
found in the literature [10]. When something is enclosed in curly braces
"{something}key" then the something has been encrypted using "key".
5.2.1 Assuming no session-identifier
client-hello C -> S: challenge, cipher_specs
server-hello S -> C: connection-id, server_certificate,
cipher_specs
client-master-key C -> S: {master_key}server_public_key
client-finish C -> S: {connection-id}client_write_key
server-verify S -> C: {challenge}server_write_key
server-finish S -> C: {new_session_id}server_write_key
5.2.2 Assuming a session-identifier was found by both client & server
client-hello C -> S: challenge, session_id, cipher_specs
server-hello S -> C: connection-id, session_id_hit
client-finish C -> S: {connection-id}client_write_key
server-verify S -> C: {challenge}server_write_key
server-finish S -> C: {session_id}server_write_key
5.2.3 Assuming a session-identifier was used and client authentication
is used
client-hello C -> S: challenge, session_id, cipher_specs
server-hello S -> C: connection-id, session_id_hit
client-finish C -> S: {connection-id}client_write_key
server-verify S -> C: {challenge}server_write_key
request-certificate S -> C: {auth_type,challenge'}
server_write_key
client-certificate C -> S: {cert_type,client_cert,
response_data}client_write_key
server-finish S -> C: {session_id}server_write_key
In this last exchange, the response_data is a function of the auth_type.
5.3 Errors
Error handling in the SSL connection protocol is very simple. When an
error is detected, the detecting party sends a message to the other party.
Errors that are not recoverable cause the client and server to abort the
secure connection. Servers and client are required to "forget" any session-
identifiers associated with a failing connection.
The SSL Handshake Protocol defines the following errors:
Hickman [page 6]
NO-CIPHER-ERROR
This error is returned by the client to the server when it cannot find
a cipher or key size that it supports that is also supported by the
server. This error is not recoverable.
NO-CERTIFICATE-ERROR
When a REQUEST-CERTIFICATE message is sent, this error may
be returned if the client has no certificate to reply with. This error
is recoverable (for client authentication only).
BAD-CERTIFICATE-ERROR
This error is returned when a certificate is deemed bad by the
receiving party. Bad means that either the signature of the
certificate was bad or that the values in the certificate were
inappropriate (e.g. a name in the certificate did not match the
expected name). This error is recoverable (for client authentication
only).
UNSUPPORTED-CERTIFICATE-TYPE-ERROR
This error is returned when a client/server receives a certificate
type that it can't support. This error is recoverable (for client
authentication only).
5.4 SSL Handshake Protocol Messages
The SSL Handshake Protocol messages are encapsulated using the SSL
Record Protocol and are composed of two parts: a single byte message
type code, and some data. The client and server exchange messages until
both ends have sent their "finished" message, indicating that they are
satisfied with the SSL Handshake Protocol conversation. While one end
may be finished, the other may not, therefore the finished end must
continue to receive SSL Handshake Protocol messages until it receives a
"finished" message from its peer.
After the pair of session keys has been determined by each party, the
message bodies are encrypted. For the client, this happens after it verifies
the session-identifier or creates a new master key and has sent it to the
server. For the server, this happens after the session-identifier is found to
be good, or the server receives the client's master key message.
The following notation is used for SSLHP messages:
char MSG-EXAMPLE
char FIELD1
char FIELD2
char THING-MSB
char THING-LSB
char THING-DATA[(MSB<<8)|LSB];
...
This notation defines the data in the protocol message, including the
message type code. The order is presented top to bottom, with the top most
element being transmitted first, and the bottom most element transferred
last.
Hickman [page 7]
For the "THING-DATA" entry, the MSB and LSB values are actually
THING-MSB and THING-LSB (respectively) and define the number of
bytes of data actually present in the message. For example, if THING-
MSB were zero and THING-LSB were 8 then the THING-DATA array
would be exactly 8 bytes long. This shorthand is used below.
Length codes are unsigned values, and when the MSB and LSB are
combined the result is an unsigned value. Unless otherwise specified
lengths values are "length in bytes".
5.5 Client Only Protocol Messages
There are several messages that are only generated by clients. These
messages are never generated by correctly functioning servers. A client
receiving such a message closes the connection to the server and returns an
error status to the application through some unspecified mechanism.
5.5.1 CLIENT-HELLO (Phase 1; Sent in the clear)
char MSG-CLIENT-HELLO
char CLIENT-VERSION-MSB
char CLIENT-VERSION-LSB
char CIPHER-SPECS-LENGTH-MSB
char CIPHER-SPECS-LENGTH-LSB
char SESSION-ID-LENGTH-MSB
char SESSION-ID-LENGTH-LSB
char CHALLENGE-LENGTH-MSB
char CHALLENGE-LENGTH-LSB
char CIPHER-SPECS-DATA[(MSB<<8)|LSB]
char SESSION-ID-DATA[(MSB<<8)|LSB]
char CHALLENGE-DATA[(MSB<<8)|LSB]
When a client first connects to a server it is required to send the CLIENT-
HELLO message. The server is expecting this message from the client as
its first message. It is an error for a client to send anything else as its
first
message.
The client sends to the server its SSL version, its cipher specs (see below),
some challenge data, and the session-identifier data. The session-identifier
data is only sent if the client found a session-identifier in its cache for the
server, and the SESSION-ID-LENGTH will be non-zero. When there is
no session-identifier for the server SESSION-ID-LENGTH must be zero.
The challenge data is used to authenticate the server. After the client and
server agree on a pair of session keys, the server returns a SERVER-
VERIFY message with the encrypted form of the CHALLENGE-DATA.
Also note that the server will not send its SERVER-HELLO message
until it has received the CLIENT-HELLO message. This is done so that
the server can indicate the status of the client's session-identifier back to
the client in the server's first message (i.e. to increase protocol efficiency
and reduce the number of round trips required).
The server examines the CLIENT-HELLO message and will verify that it
can support the client version and one of the client cipher specs. The
server can optionally edit the cipher specs, removing any entries it doesn't
Hickman [page 8]
choose to support. The edited version will be returned in the SERVER-
HELLO message if the session-identifier is not in the server's cache.
The CIPHER-SPECS-LENGTH must be greater than zero and a
multiple of 3. The SESSION-ID-LENGTH must either be zero or 16.
The CHALLENGE-LENGTH must be greater than or equal to 16 and
less than or equal to 32.
This message must be the first message sent by the client to the server.
After the message is sent the client waits for a SERVER-HELLO
message. Any other message returned by the server (other than ERROR)
is disallowed.
5.5.2 CLIENT-MASTER-KEY (Phase 1; Sent primarily in the clear)
char MSG-CLIENT-MASTER-KEY
char CIPHER-KIND[3]
char CLEAR-KEY-LENGTH-MSB
char CLEAR-KEY-LENGTH-LSB
char ENCRYPTED-KEY-LENGTH-MSB
char ENCRYPTED-KEY-LENGTH-LSB
char KEY-ARG-LENGTH-MSB
char KEY-ARG-LENGTH-LSB
char CLEAR-KEY-DATA[MSB<<8|LSB]
char ENCRYPTED-KEY-DATA[MSB<<8|LSB]
char KEY-ARG-DATA[MSB<<8|LSB]
The client sends this message when it has determined a master key for the
server to use. Note that when a session-identifier has been agreed upon,
this message is not sent.
The CIPHER-KIND field indicates which cipher was chosen from the
server's CIPHER-SPECS.
The CLEAR-KEY-DATA contains the clear portion of the MASTER-
KEY. The CLEAR-KEY-DATA is combined with the SECRET-KEY-
DATA (described shortly) to form the MASTER-KEY, with the
SECRET-KEY-DATA being the least significant bytes of the final
MASTER-KEY. The ENCRYPTED-KEY-DATA contains the secret
portions of the MASTER-KEY, encrypted using the server's public key.
The encryption block is formatted using block type 2 from PKCS#1 [5].
The data portion of the block is formatted as follows:
char SECRET-KEY-DATA[SECRET-LENGTH]
SECRET-LENGTH is the number of bytes of each session key that is
being transmitted encrypted. The SECRET-LENGTH plus the CLEAR-
KEY-LENGTH equals the number of bytes present in the cipher key (as
defined by the CIPHER-KIND). It is an error if the SECRET-LENGTH
found after decrypting the PKCS#1 formatted encryption block doesn't
match the expected value. It is also an error if CLEAR-KEY-LENGTH is
non-zero and the CIPHER-KIND is not an export cipher.
If the key algorithm needs an argument (for example, DES-CBC's
initialization vector) then the KEY-ARG-LENGTH fields will be non-
Hickman [page 9]
zero and the KEY-ARG-DATA will contain the relevant data. For the
SSL_CK_RC2_128_CBC_WITH_MD5,
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5,
SSL_CK_IDEA_128_CBC_WITH_MD5,
SSL_CK_DES_64_CBC_WITH_MD5 and
SSL_CK_DES_192_EDE3_CBC_WITH_MD5 algorithms the KEY-ARG
data must be present and be exactly 8 bytes long.
Client and server session key production is a function of the CIPHER-
CHOICE:
SSL_CK_RC4_128_WITH_MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5
SSL_CK_RC2_128_CBC_WITH_MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
SSL_CK_IDEA_128_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE,
CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE,
CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]
CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]
Where KEY-MATERIAL-0[0-15] means the first 16 bytes of the KEY-
MATERIAL-0 data, with KEY-MATERIAL-0[0] becoming the most
significant byte of the CLIENT-READ-KEY.
Data is fed to the MD5 hash function in the order shown, from left to
right: first the MASTER-KEY, then the "0" or "1", then the
CHALLENGE and then finally the CONNECTION-ID.
Note that the "0" means the ascii zero character (0x30), not a zero value.
"1" means the ascii 1 character (0x31). MD5 produces 128 bits of output
data which are used directly as the key to the cipher algorithm (The most
significant byte of the MD5 output becomes the most significant byte of
the key material).
SSL_CK_DES_64_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE,
CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]
CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]
For DES-CBC, a single 16 bytes of key material are produced using MD5.
The first 8 bytes of the MD5 digest are used as the CLIENT-READ-KEY
while the remaining 8 bytes are used as the CLIENT-WRITE-KEY. The
initialization vector is provided in the KEY-ARG-DATA. Note that the
raw key data is not parity adjusted and that this step must be performed
before the keys are legitimate DES keys.
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
Hickman [page 10]
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE,
CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE,
CONNECTION-ID ]
KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE,
CONNECTION-ID ]
CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]
CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]
CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]
CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]
CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]
CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]
Data is fed to the MD5 hash function in the order shown, from left to
right: first the MASTER-KEY, then the "0", "1" or "2", then the
CHALLENGE and then finally the CONNECTION-ID. Note that the
"0" means the ascii zero character (0x30), not a zero value. "1" means the
ascii 1 character (0x31). "2" means the ascii 2 character (0x32).
A total of 6 keys are produced, 3 for the read side DES-EDE3 cipher and 3
for the write side DES-EDE3 function. The initialization vector is
provided in the KEY-ARG-DATA. The keys that are produced are not
parity adjusted. This step must be performed before proper DES keys are
usable.
Recall that the MASTER-KEY is given to the server in the CLIENT-
MASTER-KEY message. The CHALLENGE is given to the server by
the client in the CLIENT-HELLO message. The CONNECTION-ID is
given to the client by the server in the SERVER-HELLO message. This
makes the resulting cipher keys a function of the original session and the
current session. Note that the master key is never directly used to encrypt
data, and therefore cannot be easily discovered.
The CLIENT-MASTER-KEY message must be sent after the CLIENT-
HELLO message and before the CLIENT-FINISHED message. The
CLIENT-MASTER-KEY message must be sent if the SERVER-
HELLO message contains a SESSION-ID-HIT value of 0.
5.5.3 CLIENT-CERTIFICATE (Phase 2; Sent encrypted)
char MSG-CLIENT-CERTIFICATE
char CERTIFICATE-TYPE
char CERTIFICATE-LENGTH-MSB
char CERTIFICATE-LENGTH-LSB
char RESPONSE-LENGTH-MSB
char RESPONSE-LENGTH-LSB
char CERTIFICATE-DATA[MSB<<8|LSB]
char RESPONSE-DATA[MSB<<8|LSB]
This message is sent by one an SSL client in response to a server
REQUEST-CERTIFICATE message. The CERTIFICATE-DATA
contains data defined by the CERTIFICATE-TYPE value. An ERROR
message is sent with error code NO-CERTIFICATE-ERROR when this
request cannot be answered properly (e.g. the receiver of the message has
Hickman [page 11]
no registered certificate).
CERTIFICATE-TYPE is one of:
SSL_X509_CERTIFICATE
The CERTIFICATE-DATA contains an X.509 (1988) [3] signed
certificate.
The RESPONSE-DATA contains the authentication response data. This
data is a function of the AUTHENTICATION-TYPE value sent by the
server.
When AUTHENTICATION-TYPE is
SSL_AT_MD5_WITH_RSA_ENCRYPTION then the RESPONSE-
DATA contains a digital signature of the following components (in the
order shown):
the KEY-MATERIAL-0
the KEY-MATERIAL-1 (only if defined by the cipher kind)
the KEY-MATERIAL-2 (only if defined by the cipher kind)
the CERTIFICATE-CHALLENGE-DATA (from the
REQUEST-CERTIFICATE message)
the server's signed certificate (from the SERVER-HELLO
message)
The digital signature is constructed using MD5 and then encrypted using
the clients private key, formatted according to PKCS#1's digital signature
standard [5]. The server authenticates the client by verifying the digital
signature using standard techniques. Note that other digest functions are
supported. Either a new AUTHENTICATION-TYPE can be added, or
the algorithm-id in the digital signature can be changed.
This message must be sent by the client only in response to a REQUEST-
CERTIFICATE message.
5.5.4 CLIENT-FINISHED (Phase 2; Sent encrypted)
char MSG-CLIENT-FINISHED
char CONNECTION-ID[N-1]
The client sends this message when it is satisfied with the server. Note that
the client must continue to listen for server messages until it receives a
SERVER-FINISHED message. The CONNECTION-ID data is the
original connection-identifier the server sent with its SERVER-HELLO
message, encrypted using the agreed upon session key.
"N" is the number of bytes in the message that was sent, so "N-1" is the
number of bytes in the message without the message header byte.
For version 2 of the protocol, the client must send this message after it has
received the SERVER-HELLO message. If the SERVER-HELLO
message SESSION-ID-HIT flag is non-zero then the CLIENT-
FINISHED message is sent immediately, otherwise the CLIENT-
FINISHED message is sent after the CLIENT-MASTER-KEY message.
Hickman [page 12]
5.6 Server Only Protocol Messages
There are several messages that are only generated by servers. The
messages are never generated by correctly functioning clients.
5.6.1 SERVER-HELLO (Phase 1; Sent in the clear)
char MSG-SERVER-HELLO
char SESSION-ID-HIT
char CERTIFICATE-TYPE
char SERVER-VERSION-MSB
char SERVER-VERSION-LSB
char CERTIFICATE-LENGTH-MSB
char CERTIFICATE-LENGTH-LSB
char CIPHER-SPECS-LENGTH-MSB
char CIPHER-SPECS-LENGTH-LSB
char CONNECTION-ID-LENGTH-MSB
char CONNECTION-ID-LENGTH-LSB
char CERTIFICATE-DATA[MSB<<8|LSB]
char CIPHER-SPECS-DATA[MSB<<8|LSB]
char CONNECTION-ID-DATA[MSB<<8|LSB]
The server sends this message after receiving the clients CLIENT-
HELLO message. The server returns the SESSION-ID-HIT flag
indicating whether or not the received session-identifier is known by the
server (i.e. in the server's session-identifier cache). The SESSION-ID-
HIT flag will be non-zero if the client sent the server a session-identifier
(in the CLIENT-HELLO message with SESSION-ID-LENGTH != 0)
and the server found the client's session-identifier in its cache. If the
SESSION-ID-HIT flag is non-zero then the CERTIFICATE-TYPE,
CERTIFICATE-LENGTH and CIPHER-SPECS-LENGTH fields will
be zero.
The CERTIFICATE-TYPE value, when non-zero, has one of the values
described above (see the information on the CLIENT-CERTIFICATE
message).
When the SESSION-ID-HIT flag is zero, the server packages up its
certificate, its cipher specs and a connection-id to send to the client. Using
this information the client can generate a session key and return it to the
server with the CLIENT-MASTER-KEY message.
When the SESSION-ID-HIT flag is non-zero, both the server and the
client compute a new pair of session keys for the current session derived
from the MASTER-KEY that was exchanged when the SESSION-ID
was created. The SERVER-READ-KEY and SERVER-WRITE-KEY
are derived from the original MASTER-KEY keys in the same manner as
the CLIENT-READ-KEY and CLIENT-WRITE-KEY:
SERVER-READ-KEY = CLIENT-WRITE-KEY
SERVER-WRITE-KEY = CLIENT-READ-KEY
Note that when keys are being derived and the SESSION-ID-HIT flag is
set and the server discovers the client's session-identifier in the servers
cache, then the KEY-ARG-DATA is used from the time when the
Hickman [page 13]
SESSION-ID was established. This is because the client does not send
new KEY-ARG-DATA (recall that the KEY-ARG-DATA is sent only in
the CLIENT-MASTER-KEY message).
The CONNECTION-ID-DATA is a string of randomly generated bytes
used by the server and client at various points in the protocol. The
CLIENT-FINISHED message contains an encrypted version of the
CONNECTION-ID-DATA. The length of the CONNECTION-ID must
be between 16 and than 32 bytes, inclusive.
The CIPHER-SPECS-DATA define a cipher type and key length (in bits)
that the receiving end supports. Each SESSION-CIPHER-SPEC is 3
bytes long and looks like this:
char CIPHER-KIND-0
char CIPHER-KIND-1
char CIPHER-KIND-2
Where CIPHER-KIND is one of:
SSL_CK_RC4_128_WITH_MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5
SSL_CK_RC2_128_CBC_WITH_MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
SSL_CK_IDEA_128_CBC_WITH_MD5
SSL_CK_DES_64_CBC_WITH_MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
This list is not exhaustive and may be changed in the future.
The SSL_CK_RC4_128_EXPORT40_WITH_MD5 cipher is an RC4
cipher where some of the session key is sent in the clear and the rest is sent
encrypted (exactly 40 bits of it). MD5 is used as the hash function for
production of MAC's and session key's. This cipher type is provided to
support "export" versions (i.e. versions of the protocol that can be
distributed outside of the United States) of the client or server.
An exportable implementation of the SSL Handshake Protocol will have
secret key lengths restricted to 40 bits. For non-export implementations
key lengths can be more generous (we recommend at least 128 bits). It is
permissible for the client and server to have a non-intersecting set of
stream ciphers. This, simply put, means they cannot communicate.
Version 2 of the SSL Handshake Protocol defines the
SSL_CK_RC4_128_WITH_MD5 to have a key length of 128 bits. The
SSL_CK_RC4_128_EXPORT40_WITH_MD5 also has a key length of
128 bits. However, only 40 of the bits are secret (the other 88 bits are sent
in the clear by the client to the server).
The SERVER-HELLO message is sent after the server receives the
CLIENT-HELLO message, and before the server sends the SERVER-
VERIFY message.
5.6.2 SERVER-VERIFY (Phase 1; Sent encrypted)
char MSG-SERVER-VERIFY
Hickman [page 14]
char CHALLENGE-DATA[N-1]
The server sends this message after a pair of session keys (SERVER-
READ-KEY and SERVER-WRITE-KEY) have been agreed upon either
by a session-identifier or by explicit specification with the CLIENT-
MASTER-KEY message. The message contains an encrypted copy of the
CHALLENGE-DATA sent by the client in the CLIENT-HELLO
message.
"N" is the number of bytes in the message that was sent, so "N-1" is the
number of bytes in the CHALLENGE-DATA without the message
header byte.
This message is used to verify the server as follows. A legitimate server
will have the private key that corresponds to the public key contained in
the server certificate that was transmitted in the SERVER-HELLO
message. Accordingly, the legitimate server will be able to extract and
reconstruct the pair of session keys (SERVER-READ-KEY and
SERVER-WRITE-KEY). Finally, only a server that has done the
extraction and decryption properly can correctly encrypt the
CHALLENGE-DATA. This, in essence, "proves" that the server has the
private key that goes with the public key in the server's certificate.
The CHALLENGE-DATA must be the exact same length as originally
sent by the client in the CLIENT-HELLO message. Its value must match
exactly the value sent in the clear by the client in the CLIENT-HELLO
message. The client must decrypt this message and compare the value
received with the value sent, and only if the values are identical is the
server to be "trusted". If the lengths do not match or the value doesn't
match then the connection is to be closed by the client.
This message must be sent by the server to the client after either detecting
a session-identifier hit (and replying with a SERVER-HELLO message
with SESSION-ID-HIT not equal to zero) or when the server receives the
CLIENT-MASTER-KEY message. This message must be sent before
any Phase 2 messages or a SERVER-FINISHED message.
5.6.3 SERVER-FINISHED (Phase 2; Sent encrypted)
char MSG-SERVER-FINISHED
char SESSION-ID-DATA[N-1]
The server sends this message when it is satisfied with the clients security
handshake and is ready to proceed with transmission/reception of the
higher level protocols data. The SESSION-ID-DATA is used by the client
and the server at this time to add entries to their respective session-
identifier caches. The session-identifier caches must contain a copy of the
MASTER-KEY sent in the CLIENT-MASTER-KEY message as the
master key is used for all subsequent session key generation.
"N" is the number of bytes in the message that was sent, so "N-1" is the
number of bytes in the SESSION-ID-DATA without the message header
byte.
This message must be sent after the SERVER-VERIFY message.
Hickman [page 15]
5.6.4 REQUEST-CERTIFICATE (Phase 2; Sent encrypted)
char MSG-REQUEST-CERTIFICATE
char AUTHENTICATION-TYPE
char CERTIFICATE-CHALLENGE-DATA[N-2]
A server may issue this request at any time during the second phase of the
connection handshake, asking for the client's certificate. The client
responds with a CLIENT-CERTIFICATE message immediately if it has
one, or an ERROR message (with error code NO-CERTIFICATE-
ERROR) if it doesn't. The CERTIFICATE-CHALLENGE-DATA is a
short byte string (whose length is greater than or equal to 16 bytes and less
than or equal to 32 bytes) that the client will use to respond to this
message.
The AUTHENTICATION-TYPE value is used to choose a particular
means of authenticating the client. The following types are defined:
SSL_AT_MD5_WITH_RSA_ENCRYPTION
The SSL_AT_MD5_WITH_RSA_ENCRYPTION type requires that the
client construct an MD5 message digest using information as described
above in the section on the CLIENT-CERTIFICATE message. Once the
digest is created, the client encrypts it using its private key (formatted
according to the digital signature standard defined in PKCS#1). The server
authenticates the client when it receives the CLIENT-CERTIFICATE
message.
This message may be sent after a SERVER-VERIFY message and before
a SERVER-FINISHED message.
5.7 Client/Server Protocol Messages
These messages are generated by both the client and the server.
5.7.1 ERROR (Sent clear or encrypted)
char MSG-ERROR
char ERROR-CODE-MSB
char ERROR-CODE-LSB
This message is sent when an error is detected. After the message is sent,
the sending party shuts the connection down. The receiving party records
the error and then shuts its connection down.
This message is sent in the clear if an error occurs during session key
negotiation. After a session key has been agreed upon, errors are sent
encrypted like all other messages.
Appendix A: ASN.1 Syntax For Certificates
Certificates are used by SSL to authenticate servers and clients. SSL
Certificates are based largely on the X.509 [3] certificates. An X.509
certificate contains the following information (in ASN.1 [1] notation):
Hickman [page 16]
X.509-Certificate ::= SEQUENCE {
certificateInfo CertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
CertificateInfo ::= SEQUENCE {
version [0] Version DEFAULT v1988,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo
}
Version ::= INTEGER { v1988(0) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY ALGORITHM OPTIONAL
}
For SSL's purposes we restrict the values of some of the X.509 fields:
The X.509-Certificate::signatureAlgorithm and
CertificateInfo::signature fields must be identical in value.
The issuer name must resolve to a name that is deemed acceptable by
the application using SSL. How the application using SSL does this is
outside the scope of this memo.
Certificates are validated using a few straightforward steps. First, the
signature on the certificate is checked and if invalid, the certificate is
invalid (either a transmission error or an attempted forgery occurred).
Next, the CertificateInfo::issuer field is verified to be an issuer that the
application trusts (using an unspecified mechanism). The
CertificateInfo::validity field is checked against the current date and
verified.
Finally, the CertificateInfo::subject field is checked. This check is
optional and depends on the level of trust required by the application using
SSL.
Hickman [page 17]
Appendix B: Attribute Types and Object Identifiers
SSL uses a subset of the X.520 selected attribute types as well as a
few specific object identifiers. Future revisions of the SSL protocol
may include support for more attribute types and more object
identifiers.
B.1 Selected attribute types
commonName { attributeType 3 }
The common name contained in the distinguished name contained
within a certificate issuer or certificate subject.
countryName { attributeType 6 }
The country name contained in the distinguished name contained
within a certificate issuer or certificate subject.
localityName { attributeType 7 }
The locality name contained in the distinguished name contained
within a certificate issuer or certificate subject.
stateOrProvinceName { attributeType 8 }
The state or province name contained in the distinguished name
contained within a certificate issuer or certificate subject.
organizationName { attributeType 10 }
The organization name contained in the distinguished name contained
within a certificate issuer or certificate subject.
organizationalUnitName { attributeType 11 }
The organizational unit name contained in the distinguished name
contained within a certificate issuer or certificate subject.
B.2 Object identifiers
md2withRSAEncryption { ... pkcs(1) 1 2 }
The object identifier for digital signatures that use both MD2 and RSA
encryption. Used by SSL for certificate signature verification.
md5withRSAEncryption { ... pkcs(1) 1 4 }
The object identifier for digital signatures that use both MD5 and RSA
encryption. Used by SSL for certificate signature verification.
rc4 { ... rsadsi(113549) 3 4 }
The RC4 symmetric stream cipher algorithm used by SSL for bulk
encryption.
Appendix C: Protocol Constant Values
This section describes various protocol constants. A special value needs
mentioning - the IANA reserved port number for "https" (HTTP using
SSL). IANA has reserved port number 443 (decimal) for "https". IANA
has also reserved port number 465 for "ssmtp" and port number 563 for
"snntp".
Hickman [page 18]
C.1 Protocol Version Codes
#define SSL_CLIENT_VERSION 0x0002
#define SSL_SERVER_VERSION 0x0002
C.2 Protocol Message Codes
The following values define the message codes that are used by version
2 of the SSL Handshake Protocol.
#define SSL_MT_ERROR 0
#define SSL_MT_CLIENT_HELLO 1
#define SSL_MT_CLIENT_MASTER_KEY 2
#define SSL_MT_CLIENT_FINISHED 3
#define SSL_MT_SERVER_HELLO 4
#define SSL_MT_SERVER_VERIFY 5
#define SSL_MT_SERVER_FINISHED 6
#define SSL_MT_REQUEST_CERTIFICATE 7
#define SSL_MT_CLIENT_CERTIFICATE 8
C.3 Error Message Codes
The following values define the error codes used by the ERROR message.
#define SSL_PE_NO_CIPHER 0x0001
#define SSL_PE_NO_CERTIFICATE 0x0002
#define SSL_PE_BAD_CERTIFICATE 0x0004
#define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE 0x0006
C.4 Cipher Kind Values
The following values define the CIPHER-KIND codes used in the
CLIENT-HELLO and SERVER-HELLO messages.
#define SSL_CK_RC4_128_WITH_MD5
0x01,0x00,0x80
#define SSL_CK_RC4_128_EXPORT40_WITH_MD5
0x02,0x00,0x80
#define SSL_CK_RC2_128_CBC_WITH_MD5
0x03,0x00,0x80
#define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
0x04,0x00,0x80
#define SSL_CK_IDEA_128_CBC_WITH_MD5
0x05,0x00,0x80
#define SSL_CK_DES_64_CBC_WITH_MD5
0x06,0x00,0x40
#define SSL_CK_DES_192_EDE3_CBC_WITH_MD5
0x07,0x00,0xC0
C.5 Certificate Type Codes
The following values define the certificate type codes used in the
SERVER-HELLO and CLIENT-CERTIFICATE messages.
#define SSL_CT_X509_CERTIFICATE 0x01
Hickman [page 19]
C.6 Authentication Type Codes
The following values define the authentication type codes used in the
REQUEST-CERTIFICATE message.
#define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01
C.7 Upper/Lower Bounds
The following values define upper/lower bounds for various protocol
parameters.
#define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS 256
#define SSL_MAX_SESSION_ID_LENGTH_IN_BYTES 16
#define SSL_MIN_RSA_MODULUS_LENGTH_IN_BYTES 64
#define SSL_MAX_RECORD_LENGTH_2_BYTE_HEADER 32767
#define SSL_MAX_RECORD_LENGTH_3_BYTE_HEADER 16383
C.8 Recommendations
Because protocols have to be implemented to be of value, we recommend
the following values for various operational parameters. This is only a
recommendation, and not a strict requirement for conformance to the
protocol.
Session-identifier Cache Timeout
Session-identifiers are kept in SSL clients and SSL servers. Session-
identifiers should have a lifetime that serves their purpose (namely,
reducing the number of expensive public key operations for a single
client/server pairing). Consequently, we recommend a maximum session-
identifier cache timeout value of 100 seconds. Given a server that can
perform N private key operations per second, this reduces the server load
for a particular client by a factor of 100.
Appendix D: Attacks
In this section we attempt to describe various attacks that might be used
against the SSL protocol. This list is not guaranteed to be exhaustive. SSL
was defined to thwart these attacks.
D.1 Cracking Ciphers
SSL depends on several cryptographic technologies. RSA Public Key
encryption [5] is used for the exchange of the session key and client/server
authentication. Various cryptographic algorithms are used for the session
cipher. If successful cryptographic attacks are made against these
technologies then SSL is no longer secure.
Attacks against a specific communications session can be made by
recording the session, and then spending some large number of compute
cycles to crack either the session key or the RSA public key until the
communication can be seen in the clear. This approach is easier than
cracking the cryptographic technologies for all possible messages. Note
that SSL tries to make the cost of such of an attack greater than the
Hickman [page 20]
benefits gained from a successful attack, thus making it a waste of
money/time to perform such an attack.
There have been many books [9] and papers [10] written on cryptography.
This document does not attempt to reference them all.
D.2 Clear Text Attack
A clear text attack is done when the attacker has an idea of what kind of
message is being sent using encryption. The attacker can generate a data
base whose keys are the encrypted value of the known text (or clear text),
and whose values are the session cipher key (we call this a "dictionary").
Once this data base is constructed, a simple lookup function identifies the
session key that goes with a particular encrypted value. Once the session
key is known, the entire message stream can be decrypted. Custom
hardware can be used to make this cost effective and very fast.
Because of the very nature of SSL clear text attacks are possible. For
example, the most common byte string sent by an HTTP client application
to an HTTP server is "GET". SSL attempts to address this attack by using
large session cipher keys. First, the client generates a key which is larger
than allowed by export, and sends some of it in the clear to the server (this
is allowed by United States government export rules). The clear portion of
the key concatenated with the secret portion make a key which is very
large (for RC4, exactly 128 bits).
The way that this "defeats" a clear text attack is by making the amount of
custom hardware needed prohibitively large. Every bit added to the length
of the session cipher key increases the dictionary size by a factor of 2. By
using a 128 bit session cipher key length the size of the dictionary required
is beyond the ability of anyone to fabricate (it would require more atoms to
construct than exist in the entire universe). Even if a smaller dictionary is
to be used, it must first be generated using the clear key bits. This is a time
consumptive process and also eliminates many possible custom hardware
architectures (e.g. static prom arrays).
The second way that SSL attacks this problem is by using large key
lengths when permissible (e.g. in the non-export version). Large key sizes
require larger dictionaries (just one more bit of key size doubles the size of
the dictionary). SSL attempts to use keys that are 128 bits in length.
Note that the consequence of the SSL defense is that a brute force attack
becomes the cheapest way to attack the key. Brute force attacks have well
known space/time tradeoffs and so it becomes possible to define a cost of
the attack. For the 128 bit secret key, the known cost is essentially infinite.
For the 40 bit secret key, the cost is much smaller, but still outside the
range of the "random hacker".
D.3 Replay
The replay attack is simple. A bad-guy records a communication session
between a client and server. Later, it reconnects to the server, and plays
back the previously recorded client messages. SSL defeats this attack
using a "nonce" (the connection-id) which is "unique" to the connection. In
theory the bad-guy cannot predict the nonce in advance as it is based on a
Hickman [page 21]
set of random events outside the bad-guys control, and therefore the bad-
guy cannot respond properly to server requests.
A bad-guy with large resources can record many sessions between a client
and a server, and attempt to choose the right session based on the nonce
the server sends initially in its SERVER-HELLO message. However, SSL
nonces are at least 128 bits long, so a bad-guy would need to record
approximately 2^64 nonces to even have a 50% chance of choosing the
right session. This number is sufficiently large that one cannot
economically construct a device to record 2^64 messages, and therefore
the odds are overwhelmingly against the replay attack ever being
successful.
D.4 The Man In The Middle
The man in the middle attack works by having three people in a
communications session: the client, the server, and the bad guy. The bad
guy sits between the client and the server on the network and intercepts
traffic that the client sends to the server, and traffic that the server
sends to
the client.
The man in the middle operates by pretending to be the real server to the
client. With SSL this attack is impossible because of the usage of server
certificates. During the security connection handshake the server is
required to provide a certificate that is signed by a certificate authority.
Contained in the certificate is the server's public key as well as its name
and the name of the certificate issuer. The client verifies the certificate by
first checking the signature and then verifying that the name of the issuer
is somebody that the client trusts.
In addition, the server must encrypt something with the private key that
goes with the public key mentioned in the certificate. This in essence is a
single pass "challenge response" mechanism. Only a server that has both
the certificate and the private key can respond properly to the challenge.
If the man in the middle provides a phony certificate, then the signature
check will fail. If the certificate provided by the bad guy is legitimate, but
for the bad guy instead of for the real server, then the signature will pass
but the name check will fail (note that the man in the middle cannot forge
certificates without discovering a certificate authority's private key).
Finally, if the bad guy provides the real server's certificate then the
signature check will pass and the name check will pass. However, because
the bad guy does not have the real server's private key, the bad guy cannot
properly encode the response to the challenge code, and this check will
fail.
In the unlikely case that a bad guy happens to guess the response code to
the challenge, the bad guy still cannot decrypt the session key and
therefore cannot examine the encrypted data.
Hickman [page 22]
Appendix E: Terms
Application Protocol
An application protocol is a protocol that normally layers directly on
top of TCP/IP. For example: HTTP, TELNET, FTP, and SMTP.
Authentication
Authentication is the ability of one entity to determine the identity of
another entity. Identity is defined by this document to mean the
binding between a public key and a name and the implicit ownership
of the corresponding private key.
Bulk Cipher
This term is used to describe a cryptographic technique with certain
performance properties. Bulk ciphers are used when large quantities of
data are to be encrypted/decrypted in a timely manner. Examples
include RC2, RC4, and IDEA.
Client
In this document client refers to the application entity that is initiates a
connection to a server.
CLIENT-READ-KEY
The session key that the client uses to initialize the client read cipher.
This key has the same value as the SERVER-WRITE-KEY.
CLIENT-WRITE-KEY
The session key that the client uses to initialize the client write cipher.
This key has the same value as the SERVER-READ-KEY.
MASTER-KEY
The master key that the client and server use for all session key
generation. The CLIENT-READ-KEY, CLIENT-WRITE-KEY,
SERVER-READ-KEY and SERVER-WRITE-KEY are generated
from the MASTER-KEY.
MD2
MD2 [8] is a hashing function that converts an arbitrarily long data
stream into a digest of fixed size. This function predates MD5 [7]
which is viewed as a more robust hash function [9].
MD5
MD5 [7] is a hashing function that converts an arbitrarily long data
stream into a digest of fixed size. The function has certain properties
that make it useful for security, the most important of which is it's
inability to be reversed.
Nonce
A randomly generated value used to defeat "playback" attacks. One
party randomly generates a nonce and sends it to the other party. The
receiver encrypts it using the agreed upon secret key and returns it to
the sender. Because the nonce was randomly generated by the sender
this defeats playback attacks because the replayer can't know in
advance the nonce the sender will generate. The receiver denies
connections that do not have the correctly encrypted nonce.
Hickman [page 23]
Non-repudiable Information Exchange
When two entities exchange information it is sometimes valuable to
have a record of the communication that is non-repudiable. Neither
party can then deny that the information exchange occurred. Version 2
of the SSL protocol does not support Non-repudiable information
exchange.
Public Key Encryption
Public key encryption is a technique that leverages asymmetric ciphers.
A public key system consists of two keys: a public key and a private
key. Messages encrypted with the public key can only be decrypted
with the associated private key. Conversely, messages encrypted with
the private key can only be decrypted with the public key. Public key
encryption tends to be extremely compute intensive and so is not
suitable as a bulk cipher.
Privacy
Privacy is the ability of two entities to communicate without fear of
eavesdropping. Privacy is often implemented by encrypting the
communications stream between the two entities.
RC2, RC4
Proprietary bulk ciphers invented by RSA (There is no good reference
to these as they are unpublished works; however, see [9]). RC2 is
block cipher and RC4 is a stream cipher.
Server
The server is the application entity that responds to requests for
connections from clients. The server is passive, waiting for requests
from clients.
Session cipher
A session cipher is a "bulk" cipher that is capable of encrypting or
decrypting arbitrarily large amounts of data. Session ciphers are used
primarily for performance reasons. The session ciphers used by this
protocol are symmetric. Symmetric ciphers have the property of using
a single key for encryption and decryption.
Session identifier
A session identifier is a random value generated by a client that
identifies itself to a particular server. The session identifier can be
thought of as a handle that both parties use to access a recorded secret
key (in our case a session key). If both parties remember the session
identifier then the implication is that the secret key is already known
and need not be negotiated.
Session key
The key to the session cipher. In SSL there are four keys that are called
session keys: CLIENT-READ-KEY, CLIENT-WRITE-KEY,
SERVER-READ-KEY, and SERVER-WRITE-KEY.
SERVER-READ-KEY
The session key that the server uses to initialize the server read cipher.
This key has the same value as the CLIENT-WRITE-KEY.
Hickman [page 24]
SERVER-WRITE-KEY
The session key that the server uses to initialize the server write cipher.
This key has the same value as the CLIENT-READ-KEY.
Symmetric Cipher
A symmetric cipher has the property that the same key can be used for
decryption and encryption. An asymmetric cipher does not have this
behavior. Some examples of symmetric ciphers: IDEA, RC2, RC4.
References
[1] CCITT. Recommendation X.208: "Specification of Abstract Syntax
Notation One (ASN.1). 1988.
[2] CCITT. Recommendation X.209: "Specification of Basic Encoding
Rules for Abstract Syntax Notation One (ASN.1). 1988.
[3] CCITT. Recommendation X.509: "The Directory - Authentication
Framework". 1988.
[4] CCITT. Recommendation X.520: "The Directory - Selected Attribute
Types". 1988.
[5] RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5,
November 1993.
[6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard,
Version 1.5, November 1993.
[7] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April
1992.
[8] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April
1992.
[9] B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source
Code in C, Published by John Wiley & Sons, Inc. 1994.
[10] M. Abadi and R. Needham. Prudent engineering practice for
cryptographic protocols. 1994.
Patent Statement
This version of the SSL protocol relies on the use of patented public key
encryption technology for authentication and encryption. The Internet
Standards Process as defined in RFC 1310 requires a written statement
from the Patent holder that a license will be made available to applicants
under reasonable terms and conditions prior to approving a specification as
a Proposed, Draft or Internet Standard.
The Massachusetts Institute of Technology and the Board of Trustees of
the Leland Stanford Junior University have granted Public Key Partners
(PKP) exclusive sub-licensing rights to the following patents issued in the
Hickman [page 25]
United States, and all of their corresponding foreign patents:
Cryptographic Apparatus and Method ("Diffie-Hellman")
No. 4,200,770
Public Key Cryptographic Apparatus and Method ("Hellman-Merkle")
No. 4,218,582
Cryptographic Communications System and Method ("RSA")
No. 4,405,829
Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig")
No. 4,424,414
These patents are stated by PKP to cover all known methods of practicing
the art of Public Key encryption, including the variations collectively
known as ElGamal.
Public Key Partners has provided written assurance to the Internet Society
that parties will be able to obtain, under reasonable, nondiscriminatory
terms, the right to use the technology covered by these patents. This
assurance is documented in RFC 1170 titled "Public Key Standards and
Licenses". A copy of the written assurance dated April 20, 1990, may be
obtained from the Internet Assigned Number Authority (IANA).
The Internet Society, Internet Architecture Board, Internet Engineering
Steering Group and the Corporation for National Research Initiatives take
no position on the validity or scope of the patents and patent applications,
nor on the appropriateness of the terms of the assurance. The Internet
Society and other groups mentioned above have not made any
determination as to any other intellectual property rights which may apply
to the practice of this standard. Any further consideration of these matters
is the user's own responsibility.
Security Considerations
This entire document is about security.
Author's Address
Kipp E.B. Hickman
Netscape Communications Corp.
501 East Middlefield Rd.
Mountain View, CA 94043
kipp@netscape.com
Hickman [page 26]
|