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
|
[Documentation]
SSL 2.0 PROTOCOL SPECIFICATION
If you have questions about this protocol specification, please ask them in
Netscape's newsgroup for SSL developers, netscape.dev.ssl. More information
about the netscape.dev.ssl newsgroup may be found at this URL:
http://home.netscape.com/eng/ssl3/ssl-talk.html
------------------------------------------------------------------------
THIS PROTOCOL SPECIFICATION WAS REVISED ON NOVEMBER 29TH, 1994:
* a fundamental correction to the client-certificate authentication
protocol,
* the removal of the username/password messages,
* corrections in some of the cryptographic terminology,
* the addition of a MAC to the messages [see section 1.2],
* the allowance for different kinds of message digest algorithms.
THIS DOCUMENT WAS REVISED ON DECEMBER 22ND, 1994:
* The spec now defines the order the clear key data and secret key data
are combined to produce the master key.
* The spec now explicitly states the size of the MAC instead of making
the reader figure it out.
* The spec is more clear on the actual values used to produce the session
read and write keys.
* The spec is more clear on how many bits of the session key are used
after they are produced from the hash function.
THIS DOCUMENT WAS REVISED ON JANUARY 17TH, 1995:
* Defined the category to be informational.
* Clarified ordering of data elements in various places.
* Defined DES-CBC cipher kind and key construction.
* Defined DES-EDE3-CBC cipher kind and key construction.
THIS DOCUMENT WAS REVISED ON JANUARY 24TH, 1995:
* Fixed bug in definition of CIPHER-CHOICE in CLIENT-MASTER-KEY message.
The previous spec erroneously indicated that the CIPHER-CHOICE was an
index into the servers CIPHER-SPECS-DATA array, when it was actually
supposed to be the CIPHER-KIND value chosen by the client.
* Clarified the values of the KEY-ARG-DATA.
THIS DOCUMENT WAS REVISED ON FEBRUARY 9TH, 1995:
The spec has been clarified to indicate the byte order of sequence
numbers when they are being applied to the MAC hash function.
* The spec now defines the acceptable length range of the CONNECTION-ID
parameter (sent by the server in the SERVER-HELLO message).
* Simplified the specification of the CIPHER-KIND data. The spec language
has been changed yet the format remains compatible with all existing
implementations. The CIPHER-KIND information is now a three byte value
which defines the type of cipher and the length of the key. The key
length is no longer separable from the CIPHER-KIND.
* Explained how the KEY-ARG-DATA is retained with the SESSION-ID when the
session-identifier cache is used.
------------------------------------------------------------------------
Experimental Kipp E.B. Hickman
Request For Comments: XXXX Netscape Communications Corp.
Category: Informational Last Update: Feb. 9th, 1995
The SSL Protocol
Status of this Memo
This is a DRAFT specification.
This RFC specifies a security protocol for the Internet community, and
requests discussion and suggestions for improvements. Distribution of
this memo is unlimited.
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.
Motivation
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.
* The channel is authenticated. The server endpoint of the
conversation is always authenticated, while the client endpoint is
optionally authenticated.
* The channel is reliable. The message transport includes a message
integrity check (using a MAC).
1. SSL Record Protocol Specification
1.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 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.
1.2 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).
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.
2. SSL Handshake Protocol Specification
2.1 SSL Handshake Protocol Flow
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.
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 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. 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.
Phase 2
The second phase is the 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 something from the
client and send a request. 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).
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 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).
2.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".
2.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
2.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
2.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.
2.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:
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).
2.4 SSL Handshake Protocol Messages
The SSL Handshake Protocol messages are encapsulated in 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 too receives a "finished" message.
After the pair of session keys has been determined by each party,
the message bodies are encrypted using it. For the client, this
happens after it verifies the session-identifier or creates a new
session 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 session 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.
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".
2.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.
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 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.
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-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
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.
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 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.
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.
2.6 Server Only Protocol Messages
There are several messages that are only generated by servers. The
messages are never generated by correctly functioning clients.
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 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.
SERVER-VERIFY (Phase 1; Sent encrypted)
char MSG-SERVER-VERIFY
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
SEVER-FINISHED message.
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.
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.
2.7 Client/Server Protocol Messages
These messages are generated by both the client and the server.
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):
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.
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".
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
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
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 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.
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.
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.
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 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 El Gamal.
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
AOL/Netscape Communications Corp.
466 Ellis Street
Mountain View, CA 94043-4042
kipp@netscape.com
|