hello everyone
Dear All， I use openssl as a server to test SSL client of our comany. the SSL client is a part of embedded system。 I used command as blow in Cygwin. openssl s_server -accept 443 -cert testserver.pem -CAfile spectra_ca.pem -cipher DES-CBC3-SHA Loading 'screen' into random state - done Using default temp DH parameters Using default temp ECDH parameters ACCEPT bad gethostbyaddr -BEGIN SSL SESSION PARAMETERS- MHUCAQECAgMABAIACgQg7anPBHTC6jqWwBj/K5J8N4aJtFvBvvo/Cc/8IadX57gE MPFpEU9fWppV85v9f4oGy5Q7eVAXqb4QGfbQ3CaHlbw9/laI6yDDWncvGJxHAo9U oqEGAgRIhahuogQCAgEspAYEBAE= -END SSL SESSION PARAMETERS- Shared ciphers:RC4-MD5:RC4-SHA:DES-CBC3-SHA:NULL-SHA CIPHER is DES-CBC3-SHA I send "11" to client from server. but I find a problem from capture software. I see two application data sent to the client. the first , it is 24 bytes. the second, it is 32 bytes. I decrypted these data , I find the , the first 8 bytes is wrong in 32 bytes. I don't understand why it have a 24 bytes application. the other, why the first 8 bytes is wrong in 32 bytes? who can help me? thanks a lot. best regards. abc_123_ok 2008-07-22
Re: hello everyone
Dear All， who can give me some advice about below problem。 Thanks Best Regards. 发件人： abc_123_ok 发送时间： 2008-07-22 17:53:34 收件人： openssl-users 抄送： 主题： hello everyone Dear All， I use openssl as a server to test SSL client of our comany. the SSL client is a part of embedded system。 I used command as blow in Cygwin. openssl s_server -accept 443 -cert testserver.pem -CAfile spectra_ca.pem -cipher DES-CBC3-SHA Loading 'screen' into random state - done Using default temp DH parameters Using default temp ECDH parameters ACCEPT bad gethostbyaddr -BEGIN SSL SESSION PARAMETERS- MHUCAQECAgMABAIACgQg7anPBHTC6jqWwBj/K5J8N4aJtFvBvvo/Cc/8IadX57gE MPFpEU9fWppV85v9f4oGy5Q7eVAXqb4QGfbQ3CaHlbw9/laI6yDDWncvGJxHAo9U oqEGAgRIhahuogQCAgEspAYEBAE= -END SSL SESSION PARAMETERS- Shared ciphers:RC4-MD5:RC4-SHA:DES-CBC3-SHA:NULL-SHA CIPHER is DES-CBC3-SHA I send "11" to client from server. but I find a problem from capture software. I see two application data sent to the client. the first , it is 24 bytes. the second, it is 32 bytes. I decrypted these data , I find the , the first 8 bytes is wrong in 32 bytes. I don't understand why it have a 24 bytes application. the other, why the first 8 bytes is wrong in 32 bytes? who can help me? thanks a lot. best regards. abc_123_ok 2008-07-22
Re: Re: hello everyone
Dear Kyle Hamilton and All,
The client receive the data properly and The server receive the data properly.
I have added padding at the behind of the data. len of the data mode 8 equal 0.
code is as following:
static void packApplicationData(DBUF_T *msgptr)
{
BYTE *ptr = dbuf_top(msgptr);
DWORD len;// = msgptr->len + 16;
//DWORD out_msglen;
/* int count; */
len = msgptr->len + macLen;
memmove(ptr + 5, ptr, msgptr->len);
memmove(ptr, header, 5);
calcClientMAC(ptr + msgptr->len + 5, 0x17, ptr + 5, msgptr->len);
//QZF add 3DES encrypted algorthim. 2008-6-24
switch (sslContext[0].cipherSuite)
{
case SSL_RSA_WITH_RC4_128_SHA:
case SSL_RSA_WITH_RC4_128_MD5:
os_rc4_crypt(&sslContext[0].eARC4, ptr + 5, len);
break;
case SSL_RSA_WITH_3DES_EDE_CBC_SHA:
{
int padlen,i;
BYTE * msg;
msg = ptr + 5;
padlen = 8 - ( len + 1 ) % 8;
if( padlen == 8 )
padlen = 0;
for( i = 0; i <= padlen; i++ )
msg[len + i] = (unsigned char) padlen;
len += padlen + 1;
des3_crypt_cbc((des3_context *)sslContext[0].key_material->ctx_enc,
DES_ENCRYPT,
len,
sslContext[0].key_material->iv_enc,
ptr + 5,
ptr + 5 );
}
break;
case SSL_RSA_WITH_NULL_SHA:
break;
default:
os_disp_puts("cipher suit error");
break;
}
ptr[2] = 0x00; //(len >> 16) & 0x00FF;
ptr[3] = (len >> 8) & 0x00FF;
ptr[4] = (len ) & 0x00FF;
msgptr->len = len + 5;//len + 5;
}
Do you mention initialization vector is IV of 3DES algorithm for CBC?
My 3DES algorithm contain IV to CBC.
the handshake can build normally.
I don't know I have problem like this.
Thanks.
Best Regards.
abc_123_ok
2008-07-23
发件人： Kyle Hamilton
发送时间： 2008-07-23 10:06:44
收件人： openssl-users@openssl.org
抄送：
主题： Re: hello everyone
Does the client receive the data properly?
Does the server receive the data properly?
You may have padding going on, you may have an initialization vector
being preset, you may have a whole bunch of things going on under the
hood. As long as both the client and the server agree on what's going
on and what to interpret data as, there's no problems.
There have been some obfuscations made to help prevent CBC attacks, as
well (please see the TLS v1.0 and TLS v1.1 RFCs for references on what
the attacks are and why these obfuscations are necessary to defeat
them).
-Kyle H
2008/7/22 abc_123_ok <[EMAIL PROTECTED] >:
> Dear All，
>
> I use openssl as a server to test SSL client of our comany. the SSL client
> is a part of embedded system。
> I used command as blow in Cygwin.
>
>
> openssl s_server -accept 443 -cert testserver.pem -CAfile spectra_ca.pem
> -cipher DES-CBC3-SHA
>
> Loading 'screen' into random state - done
> Using default temp DH parameters
> Using default temp ECDH parameters
> ACCEPT
>
> bad gethostbyaddr
> -BEGIN SSL SESSION PARAMETERS-
> MHUCAQECAgMABAIACgQg7anPBHTC6jqWwBj/K5J8N4aJtFvBvvo/Cc/8IadX57gE
> MPFpEU9fWppV85v9f4oGy5Q7eVAXqb4QGfbQ3CaHlbw9/laI6yDDWncvGJxHAo9U
> oqEGAgRIhahuogQCAgEspAYEBAE=
> -END SSL SESSION PARAMETERS-
> Shared ciphers:RC4-MD5:RC4-SHA:DES-CBC3-SHA:NULL-SHA
> CIPHER is DES-CBC3-SHA
>
>
> I send "11" to client from server.
> but I find a problem from capture software.
>
> I see two application data sent to the client.
> the first , it is 24 bytes. the second, it is 32 bytes. I decrypted these
> data , I find the , the first 8 bytes is wrong in 32 bytes.
>
> I don't understand why it have a 24 bytes application. the other, why the
> first 8 bytes
> is wrong in 32 bytes?
>
> who can help me?
>
> thanks a lot.
> best regards.
>
>
> abc_123_ok
> 2008-07-22
:??I"???ì(?鬲Z+?K ?+??x
???鬲[?z?(?鬲Z+?
??f?y? ?f???h??)z{,??
Re: Re: hello everyone
Dear Alan Wolfe & All, I send some data to server, no problem server can receive the data normally. but when I send some data to client with openssl s_server. for exmple, I enter "aa" on server with openssl s_server, it is 10 'a'. but I receive the data from client, I found the data have two application data. the first is 24 bytes. and the second is 32 bytes. I decrypt the data. I can't know what the 24 bytes data is . First 8 bytes of the 32 bytes data is mess, the next 2 bytes is 'a' and 'a', the next is 20 bytes mac and padding. the first 8 byte is wrong and what is the 24 bytes data before the 32 bytes? abc_123_ok 2008-07-23 发件人： Alan Wolfe 发送时间： 2008-07-23 11:04:35 收件人： openssl-users@openssl.org 抄送： 主题： Re: hello everyone just in case it helps debugging, when you said the first 8 bytes are wrong, instead of trying a pattern like "111" to send over you might try something like "12345..." so that way you can tell WHERE your data is getting messed up - ie that could show that not only is the first 8 bytes wrong, but your data begins at byte 9, which could point to a padding issue or something like that. my 2 cents in case it helps debugging (: On Tue, Jul 22, 2008 at 7:06 PM, Kyle Hamilton <[EMAIL PROTECTED]> wrote: Does the client receive the data properly? Does the server receive the data properly? You may have padding going on, you may have an initialization vector being preset, you may have a whole bunch of things going on under the hood. As long as both the client and the server agree on what's going on and what to interpret data as, there's no problems. There have been some obfuscations made to help prevent CBC attacks, as well (please see the TLS v1.0 and TLS v1.1 RFCs for references on what the attacks are and why these obfuscations are necessary to defeat them). -Kyle H 2008/7/22 abc_123_ok <[EMAIL PROTECTED]>: > Dear All， > > I use openssl as a server to test SSL client of our comany. the SSL client > is a part of embedded system。 > I used command as blow in Cygwin. > > > openssl s_server -accept 443 -cert testserver.pem -CAfile spectra_ca.pem > -cipher DES-CBC3-SHA > > Loading 'screen' into random state - done > Using default temp DH parameters > Using default temp ECDH parameters > ACCEPT > > bad gethostbyaddr > -BEGIN SSL SESSION PARAMETERS- > MHUCAQECAgMABAIACgQg7anPBHTC6jqWwBj/K5J8N4aJtFvBvvo/Cc/8IadX57gE > MPFpEU9fWppV85v9f4oGy5Q7eVAXqb4QGfbQ3CaHlbw9/laI6yDDWncvGJxHAo9U > oqEGAgRIhahuogQCAgEspAYEBAE= > -END SSL SESSION PARAMETERS- > Shared ciphers:RC4-MD5:RC4-SHA:DES-CBC3-SHA:NULL-SHA > CIPHER is DES-CBC3-SHA > > > I send "11" to client from server. > but I find a problem from capture software. > > I see two application data sent to the client. > the first , it is 24 bytes. the second, it is 32 bytes. I decrypted these > data , I find the , the first 8 bytes is wrong in 32 bytes. > > I don't understand why it have a 24 bytes application. the other, why the > first 8 bytes > is wrong in 32 bytes? > > who can help me? > > thanks a lot. > best regards. > > > abc_123_ok > 2008-07-22
Re: Re: hello everyone
16 f2 4c 55 36 8d b3 75 60 47 08 cb 5e 17 6b 3c cf f4 99 bf 49 91 ba 8c ea 9d d5 54 d9 47 6a d0 56 db 9e 64 c1 b9 13 ea d8 21 3a a1 30 dd 06 74 da 67 b7 70 96 e4 be d7 00 f5 09 34 05 52 7f b4 dd 08 c7 4c a5 80 06 45 33 f4 7a aa 47 02 6e 6f 1d be be 84 26 71 84 52 88 e4 d8 09 de f8 a9 c9 73 5e 45 76 40 ea 75 45 85 70 fe 67 29 e5 e9 47 10 87 a4 8d fa e0 7f 13 be 97 74 b4 86 bb a4 2a ea 87 04 ea 97 b6 ed ce f6 2b 10 21 a9 2f 8d 26 81 46 9f a8 b9 20 78 60 d7 6f 3e 9f 54 e5 3d c6 e5 8d df c8 cc 42 ed 69 0f 56 11 f1 8c 2e d3 bb 0c 74 30 25 8a 7a 0d 32 f4 53 21 fa 23 3f 96 23 e9 cb f4 83 9e 51 a9 4a 8a 1a c3 3a ad 11 8b 4c 13 63 43 54 30 f9 f6 8e cc dc df 66 dd 1f 38 e4 70 d8 1c 4d 90 <<< SSL 3.0 ChangeCipherSpec [length 0001] 01 <<< SSL 3.0 Handshake [length 0028], Finished 14 00 00 24 83 1c f4 7e d0 0f c8 f5 4a 96 00 62 52 07 d1 58 f6 c0 62 d4 26 e0 3f 95 58 f6 2f 89 2e 99 5d 42 24 ac 7e b0 >>> SSL 3.0 ChangeCipherSpec [length 0001] 01 >>> SSL 3.0 Handshake [length 0028], Finished 14 00 00 24 00 37 db f3 f9 3a 39 97 57 0f c7 2e 09 9b 35 eb ce 05 8c e6 1f a1 75 29 25 a7 70 66 a2 6e e9 7a ca ad b4 46 -BEGIN SSL SESSION PARAMETERS- MHUCAQECAgMABAIACgQgnWVvQbwFf5Gr904L0rn0WJEIhemkeqYiXk71fRVFEQkE ML378r+okGbVD4yf09cY80+DHauG3lietdTufBfSwIhXzfr3Z65yXHkIhzqNLiaS eaEGAgRIhwIzogQCAgEspAYEBAE= -END SSL SESSION PARAMETERS- Shared ciphers:RC4-MD5:RC4-SHA:DES-CBC3-SHA:NULL-SHA CIPHER is DES-CBC3-SHA 23456789aa 23456789 23456789 is message the server received in. and the aa is message the server send out. what problem is it. please help me, I am a new member, I don't really understand I should be how to go on. I am halt here. abc_123_ok 2008-07-23 发件人： Alan Wolfe 发送时间： 2008-07-23 11:04:35 收件人： openssl-users@openssl.org 抄送： 主题： Re: hello everyone just in case it helps debugging, when you said the first 8 bytes are wrong, instead of trying a pattern like "111" to send over you might try something like "12345..." so that way you can tell WHERE your data is getting messed up - ie that could show that not only is the first 8 bytes wrong, but your data begins at byte 9, which could point to a padding issue or something like that. my 2 cents in case it helps debugging (: On Tue, Jul 22, 2008 at 7:06 PM, Kyle Hamilton <[EMAIL PROTECTED]> wrote: Does the client receive the data properly? Does the server receive the data properly? You may have padding going on, you may have an initialization vector being preset, you may have a whole bunch of things going on under the hood. As long as both the client and the server agree on what's going on and what to interpret data as, there's no problems. There have been some obfuscations made to help prevent CBC attacks, as well (please see the TLS v1.0 and TLS v1.1 RFCs for references on what the attacks are and why these obfuscations are necessary to defeat them). -Kyle H 2008/7/22 abc_123_ok <[EMAIL PROTECTED]>: > Dear All， > > I use openssl as a server to test SSL client of our comany. the SSL client > is a part of embedded system。 > I used command as blow in Cygwin. > > > openssl s_server -accept 443 -cert testserver.pem -CAfile spectra_ca.pem > -cipher DES-CBC3-SHA > > Loading 'screen' into random state - done > Using default temp DH parameters > Using default temp ECDH parameters > ACCEPT > > bad gethostbyaddr > -BEGIN SSL SESSION PARAMETERS- > MHUCAQECAgMABAIACgQg7anPBHTC6jqWwBj/K5J8N4aJtFvBvvo/Cc/8IadX57gE > MPFpEU9fWppV85v9f4oGy5Q7eVAXqb4QGfbQ3CaHlbw9/laI6yDDWncvGJxHAo9U > oqEGAgRIhahuogQCAgEspAYEBAE= > -END SSL SESSION PARAMETERS- > Shared ciphers:RC4-MD5:RC4-SHA:DES-CBC3-SHA:NULL-SHA > CIPHER is DES-CBC3-SHA > > > I send "11" to client from server. > but I find a problem from capture software. > > I see two application data sent to the client. > the first , it is 24 bytes. the second, it is 32 bytes. I decrypted these > data , I find the , the first 8 bytes is wrong in 32 bytes. > > I don't understand why it have a 24 bytes application. the other, why the > first 8 bytes > is wrong in 32 bytes? > > who can help me? > > thanks a lot. > best regards. > > > abc_123_ok > 2008-07-22
Re: Re: Re: hello everyone
Dear All,
I use as following.
openssl s_client -connect 192.10.10.104:443 -cert client_cert.pem -CAfile
client_ca.pem
openssl s_server -accept 443 -cert server_cert.pem -CAfile server_ca.pem -cip
her DES-CBC3-SHA -ssl3
The client connect to the server of openssl, correct data is received and
sent on the both ends.
but I can see it have more 24 bytes befor actual data in the capture software.
I want to know what the 24 byte is.
thank you, anyone help me?
Best Regards.
abc_123_ok
2008-07-24
发件人： abc_123_ok
发送时间： 2008-07-23 18:11:51
收件人： openssl-users@openssl.org
抄送：
主题： Re: Re: hello everyone
Dear ,
the data is client receive application data containing the 24 bytes and the 32
bytes from server.
00 50 c2 0f 5f fe 00 15 58 18 1a 53 08 00 45 00 .P.._... X..S..E.
0010 00 6a 5d 93 40 00 80 06 08 7b c0 0a 0a 68 c0 0a [EMAIL PROTECTED]
.{...h..
0020 0a 03 01 bb c3 8a e7 47 92 f4 08 90 2e 10 50 18 ...G ..P.
0030 42 9f 4b d6 00 00 17 03 00 00 18 31 a5 69 cf fe B.K. ...1.i..
0040 53 df 08 4e f6 9b 40 b7 72 0d e8 cf 33 50 18 29 [EMAIL PROTECTED]
r...3P.)
0050 5a 64 30 17 03 00 00 20 38 f1 93 21 70 b8 08 c9 Zd0 8..!p...
0060 ed 47 09 d8 bd 83 05 80 6d 1e 7e b5 c6 ae 69 9c .G.. m.~...i.
0070 3d 9d 77 4b fb 55 de 4d=.wK.U.M
the below data is in server opening the -msg option.
$ openssl s_server -accept 443 -cert testserver.pem -CAfile spectra_ca.pem -cip
her DES-CBC3-SHA -msg
Loading 'screen' into random state - done
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
bad gethostbyaddr
<<< SSL 3.0 Handshake [length 0053], ClientHello
01 00 00 4f 03 00 25 72 dd f8 9f 09 2e fc f1 b5
f7 4b 2a 38 56 5e a0 53 4c 26 af e8 ba 74 17 f0
73 fa 36 14 47 c4 20 98 33 8e 43 8a e9 27 23 29
8f ea 2b 37 5a 61 40 49 6d a2 07 fd 24 45 99 5b
3b 66 30 e0 e2 11 d5 00 08 00 04 00 05 00 0a 00
02 01 00
>>> SSL 3.0 Handshake [length 004a], ServerHello
02 00 00 46 03 00 48 87 02 33 6d 20 3f 1c 83 37
41 1a f0 93 54 94 c5 31 24 5e 33 fe 33 95 3d 7f
95 08 75 49 3b 8b 20 9d 65 6f 41 bc 05 7f 91 ab
f7 4e 0b d2 b9 f4 58 91 08 85 e9 a4 7a a6 22 5e
4e f5 7d 15 45 11 09 00 0a 00
>>> SSL 3.0 Handshake [length 03a6], Certificate
0b 00 03 a2 00 03 9f 00 03 9c 30 82 03 98 30 82
02 80 02 09 00 fa 0d e9 7d e3 c8 ef 90 30 0d 06
09 2a 86 48 86 f7 0d 01 01 05 05 00 30 81 8d 31
0b 30 09 06 03 55 04 06 13 02 63 6e 31 12 30 10
06 03 55 04 08 13 09 67 75 61 6e 67 64 6f 6e 67
31 11 30 0f 06 03 55 04 07 13 08 73 68 65 6e 7a
68 65 6e 31 14 30 12 06 03 55 04 0a 13 0b 73 70
65 63 74 72 61 74 65 63 68 31 0b 30 09 06 03 55
04 0b 13 02 43 44 31 0c 30 0a 06 03 55 04 03 13
03 71 7a 66 31 26 30 24 06 09 2a 86 48 86 f7 0d
01 09 01 16 17 73 7a 5f 71 75 7a 66 40 73 70 65
63 74 72 61 74 65 63 68 2e 63 6f 6d 30 1e 17 0d
30 38 30 36 31 31 30 31 30 39 30 39 5a 17 0d 31
33 30 36 31 30 30 31 30 39 30 39 5a 30 81 8d 31
0b 30 09 06 03 55 04 06 13 02 63 6e 31 12 30 10
06 03 55 04 08 13 09 67 75 61 6e 67 64 6f 6e 67
31 11 30 0f 06 03 55 04 07 13 08 73 68 65 6e 7a
68 65 6e 31 14 30 12 06 03 55 04 0a 13 0b 73 70
65 63 74 72 61 74 65 63 68 31 0b 30 09 06 03 55
04 0b 13 02 43 44 31 0c 30 0a 06 03 55 04 03 13
03 71 7a 66 31 26 30 24 06 09 2a 86 48 86 f7 0d
01 09 01 16 17 73 7a 5f 71 75 7a 66 40 73 70 65
63 74 72 61 74 65 63 68 2e 63 6f 6d 30 82 01 22
30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03
82 01 0f 00 30 82 01 0a 02 82 01 01 00 c9 60 b9
29 d3 4b 14 6b d9 ed 95 43 a5 4b 4b 89 aa de ea
62 ac ae 9a b4 24 ab 71 c1 fb 09 9b 92 cb f8 06
34 c7 96 b4 b8 72 66 5b 4a dc cb 7f e4 cb 13 64
7a 4e cf 98 d7 f9 91 2f de e0 36 aa fa 2a 39 ac
6d 86 ea e2 4d cf 6f b0 da c1 59 78 cd e8 57 4e
14 29 f5 51 14 a7 cc e7 da 74 ff 4d b5 73 dc 58
84 21 d1 d9 f4 6f 75 1d f6 a2 2c bc 62 93 1f 90
97 93 25 a0 e7 f2 40 33 66 9f d3 4b 25 2f 4c 94
fd 65 6b 42 a8 d5 a1 72 42 0e 8e 5b c7 85 0a 39
d5 6d 56 27 a2 e9 a5 26 84 c5 c8 ce a7 31 51 78
de 6f fd 80 66 a8 bb a4 86 af 36 b9 ef 22 3a 4b
a4 8d 27 b3 63 5a ff 0b 12 13 bd e4 d3 29 83 50
78 6b 59 37 2d 29 8d bd fa f3 d1 77 64 db 79 b6
b1 20 a7 92 a2 5f 88 fb b7 b2 7d 59 f7 63 b1 79
1c 1c 0e 97 ba ff 96 72 ff 03 b3 40 2b dd 9f dd
f6 e4 b1 57 be dc d2 d0 7c aa 99 a3 e9 02 03 01
00 01 30 0d 06 09 2a 86 48 86 f7 0d 01 01 05 05
00 03 82 01 01 00 80 1b 5a d6 77 0c d2 17 ce d1
9b 58 d8 60 32 0c 88 a0 9e 0a 4e e5 a2 60 0e 88
65 03 5c 5e f5 3c 35 49 c0 c6 b2 9d a2 b4 d8 9b
43 b3 2b db e2 60 58 04 fc 3f d3 ad 2b 70 57 92
85 96 d8 c9 4a fa 45 05 2c fc a3 76 ff f3 25 c8
80 4c a7 64 10 7e 8e 4a 21 a6 7c a0 27 a3 4e 48
aa 01 44 b7 fa 28 7b 81 07 be 2a c0 bc 88 46 b3
d6 99 30 e8 ba fe 02 4e e6 e4 c2 e4 6e 8c 12 57
4d 43 f2 0f 87 50 33 69 66 98 fd a4 f7 73 94 e4
8b c5 1
Re: Re: Re: hello everyone
Dear Victor Duchovni， I knew what you speak as below, I have added the CBC padding and Mac and record head, but besides these len, it still have 24 bytes is more. the 24 bytes is before the application data. my problem still can n't be fixed. abc_123_ok 2008-07-25 发件人： Victor Duchovni 发送时间： 2008-07-24 22:02:49 收件人： openssl-users@openssl.org 抄送： 主题： Re: Re: Re: hello everyone On Thu, Jul 24, 2008 at 05:10:54PM +0800, abc_123_ok wrote: > I want to know what the 24 byte is. The TLS "record layer" uses a 5 byte header. The actual data is extended with a MAC, and encrypted which often adds CBC padding. You should not make any assumptions about the length of the encrypted data on the wire, there may also be packets for renegotiation if the client or server chooses to do that. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Re: Re: hello everyone
I can't fix my problem , anybady can help me? abc_123_ok 2008-07-28 发件人： abc_123_ok 发送时间： 2008-07-25 09:35:17 收件人： openssl-users@openssl.org 抄送： 主题： Re: Re: Re: hello everyone Dear Victor Duchovni， I knew what you speak as below, I have added the CBC padding and Mac and record head, but besides these len, it still have 24 bytes is more. the 24 bytes is before the application data. my problem still can n't be fixed. abc_123_ok 2008-07-25 发件人： Victor Duchovni 发送时间： 2008-07-24 22:02:49 收件人： openssl-users@openssl.org 抄送： 主题： Re: Re: Re: hello everyone On Thu, Jul 24, 2008 at 05:10:54PM +0800, abc_123_ok wrote: > I want to know what the 24 byte is. The TLS "record layer" uses a 5 byte header. The actual data is extended with a MAC, and encrypted which often adds CBC padding. You should not make any assumptions about the length of the encrypted data on the wire, there may also be packets for renegotiation if the client or server chooses to do that. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Re: Re: hello everyone
Dear Kyle，
this is my problem.
I use openssl as a server to test SSL client of our comany. the SSL client is
a part of embedded system。
I used command as blow in Cygwin.
openssl s_server -accept 443 -cert testserver.pem -CAfile spectra_ca.pem
-cipher DES-CBC3-SHA
Loading 'screen' into random state - done
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
bad gethostbyaddr
-BEGIN SSL SESSION PARAMETERS-
MHUCAQECAgMABAIACgQg7anPBHTC6jqWwBj/K5J8N4aJtFvBvvo/Cc/8IadX57gE
MPFpEU9fWppV85v9f4oGy5Q7eVAXqb4QGfbQ3CaHlbw9/laI6yDDWncvGJxHAo9U
oqEGAgRIhahuogQCAgEspAYEBAE=
-END SSL SESSION PARAMETERS-
Shared ciphers:RC4-MD5:RC4-SHA:DES-CBC3-SHA:NULL-SHA
CIPHER is DES-CBC3-SHA
I send "11" to client from server.
but I find a problem from capture software.
I see two application data sent to the client.
the first , it is 24 bytes. the second, it is 32 bytes. I decrypted these data
, I find the , the first 8 bytes is wrong in 32 bytes.
I don't understand why it have a 24 bytes application. the other, why the first
8 bytes
is wrong in 32 bytes?
who can help me?
thanks a lot.
best regards.
abc_123_ok
2008-07-28
发件人： Kyle Hamilton
发送时间： 2008-07-28 12:20:26
收件人： openssl-users@openssl.org
抄送：
主题： Re: Re: Re: hello everyone
Why is this a problem? What is the problem? SSL and TLS are designed
to abstract out underlying protocol details from the protocol client.
What are you doing that requires a 1 to 1 correspondence?
-Kyle H
2008/7/27 abc_123_ok <[EMAIL PROTECTED] >:
> I can't fix my problem , anybady can help me?
>
>
> abc_123_ok
> 2008-07-28
>
> 发件人： abc_123_ok
> 发送时间： 2008-07-25 09:35:17
> 收件人： openssl-users@openssl.org
> 抄送：
> 主题： Re: Re: Re: hello everyone
>
> Dear Victor Duchovni，
>
> I knew what you speak as below,
> I have added the CBC padding and Mac and record head, but besides these len,
> it still have 24 bytes is more. the 24 bytes is before the application
> data.
>
> my problem still can n't be fixed.
>
>
>
> abc_123_ok
> 2008-07-25
>
> 发件人： Victor Duchovni
> 发送时间： 2008-07-24 22:02:49
> 收件人： openssl-users@openssl.org
> 抄送：
> 主题： Re: Re: Re: hello everyone
>
> On Thu, Jul 24, 2008 at 05:10:54PM +0800, abc_123_ok wrote:
>
> > I want to know what the 24 byte is.
>
> The TLS "record layer" uses a 5 byte header. The actual data
> is extended with a MAC, and encrypted which often adds CBC padding.
>
> You should not make any assumptions about the length of the encrypted
> data on the wire, there may also be packets for renegotiation if the
> client or server chooses to do that.
>
> --
> Viktor.
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager [EMAIL PROTECTED]
:??I"???ì(?鬲Z+?K ?+??x
???鬲[?z?(?鬲Z+?
??f?y? ?f???h??)z{,??
Re: Re: Re: hello everyone
Dear Ger Hobbelt and All, I should introduce a situation to you. I use openssl server and client to test with DES-CBC3-SHA. server show as following: $ openssl s_server -accept 443 -cert server_cert.pem -CAfile server_ca.pem -cip her DES-CBC3-SHA Enter pass phrase for server_cert.pem: Loading 'screen' into random state - done Using default temp DH parameters Using default temp ECDH parameters ACCEPT bad gethostbyaddr -BEGIN SSL SESSION PARAMETERS- MHUCAQECAgMBBAIACgQgzaEJiBUiqFiWXT+W7XIP5ARv+G4UuwfKED2Gu4TMKLEE MDWXUKokAf0it42BTyfP8X08fGfQYnL5SutZKBYQCOJW2rN6H0dLOYZR7oEQXaQB daEGAgRIjpfBogQCAgEspAYEBAE= -END SSL SESSION PARAMETERS- Shared ciphers:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3 -SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES 128-SHA:RC4-SHA:RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP- EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP- RC4-MD5 CIPHER is DES-CBC3-SHA d s client show as following: [EMAIL PROTECTED] ~]$ openssl s_client -connect 192.10.10.104:443 -cert client_cert.pem -CAfile client_ca.pem Enter pass phrase for client_cert.pem: CONNECTED(0003) depth=1 /C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] verify return:1 depth=0 /C=CN/ST=guangdong/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] verify return:1 --- Certificate chain 0 s:/C=CN/ST=guangdong/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] i:/C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] 1 s:/C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] i:/C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] --- Server certificate -BEGIN CERTIFICATE- MIIDpDCCAw2gAwIBAgIBATANBgkqhkiG9w0BAQQFADCBjjELMAkGA1UEBhMCQ04x EjAQBgNVBAgTCWd1YW5nZG9uZzERMA8GA1UEBxMIc2hlbnpoZW4xFDASBgNVBAoT C3NwZWN0cmF0ZWNoMQswCQYDVQQLEwJSRDENMAsGA1UEAxMEcXV6ZjEmMCQGCSqG SIb3DQEJARYXc3pfcXV6ZkBzcGVjdHJhdGVjaC5jb20wHhcNMDgwNzI0MDMwNTU1 WhcNMDkwNzI0MDMwNTU1WjB7MQswCQYDVQQGEwJDTjESMBAGA1UECBMJZ3Vhbmdk b25nMRQwEgYDVQQKEwtzcGVjdHJhdGVjaDELMAkGA1UECxMCUkQxDTALBgNVBAMT BHF1emYxJjAkBgkqhkiG9w0BCQEWF3N6X3F1emZAc3BlY3RyYXRlY2guY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCxZxJlk6W+mkBzzMW7E1uz5+du1oV8 dufTuNE4YGM52uWE/6PJOai84VGPx7SWQgFslEpQ5Zso1sAstvN4c+T2Xnw9VgR8 6H1Zy2YM3WT5ca35/K33Qm0wR4o5bdHcePrqbyWoZ7XTm6eW/1IMTBNrxHtywfMX KaDTVdeMNlPDHwIDAQABo4IBIjCCAR4wCQYDVR0TBAIwADAsBglghkgBhvhCAQ0E HxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFGGAhawP CJpMWw5QCvXcmFk6CTXqMIHDBgNVHSMEgbswgbiAFNlmSaexZ1HyCe4KZG1ymGPO ICx2oYGUpIGRMIGOMQswCQYDVQQGEwJDTjESMBAGA1UECBMJZ3Vhbmdkb25nMREw DwYDVQQHEwhzaGVuemhlbjEUMBIGA1UEChMLc3BlY3RyYXRlY2gxCzAJBgNVBAsT AlJEMQ0wCwYDVQQDEwRxdXpmMSYwJAYJKoZIhvcNAQkBFhdzel9xdXpmQHNwZWN0 cmF0ZWNoLmNvbYIJAMpTAf5ipB/0MA0GCSqGSIb3DQEBBAUAA4GBAEnxl5ax3rzW /oyE086XKuC+NGmzNlstsry8fFPhrA2qjVo4G+6c1nWt/0Cu98stq30u527AjdQK zcKm+wTK1df2zlCJiXdc8FsvRZ0MQ+1xMkbf8II4hJfUo0AH+w7ub3ebtkbb3q59 /6RfJEOiQ8lKwvqNiKDmH/xY0v30+mBw -END CERTIFICATE- subject=/C=CN/ST=guangdong/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] issuer=/C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] --- No client certificate CA names sent --- SSL handshake has read 2012 bytes and written 332 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: DES-CBC3-SHA Session-ID: CDA109881522A858965D3F96ED720FE4046FF86E14BB07CA103D86BB84CC28B1 Session-ID-ctx: Master-Key: 359750AA2401FD22B78D814F27CFF17D3C7C67D06272F94AEB5928161008E256DAB37A1F474B398651EE81105DA40175 Key-Arg : None Krb5 Principal: None Start Time: 1217303619 Timeout : 300 (sec) Verify return code: 0 (ok) --- d s I use capture software catch the package as following: Secure Socket Layer TLSv1 Record Layer: Application Data Protocol: http Content Type: Application Data (23) Version: TLS 1.0 (0x0301) Length: 24 Encrypted Application Data: 83A774CFF8152C3975B7B846076398EC1439672ECE2E1D64 TLSv1 Record Layer: Application Data Protocol: http Content Type: Application Data (23) Version: TLS 1.0 (0x0301) Length: 32 Encrypted Application Data: 7C43BC0F546596DCFEA5C85022615ACEA579A6708BEA7948... the package include two application data, the first is length=24, I don't know what the 24 bytes? My english is not very good. so I can't express my idea very well. thanks abc_123_ok 2008-07-29 发件人： Ger Hobbelt 发送时间： 2008-07-28 18:09:11 收件人： openssl-users@openssl.org 抄送： 主题： Re: Re: Re: hello everyone Couple of things to test/check next: up to now you've fed it sequences of 8 bytes which, as you report, decrypt correctly. See what your current code does for longer input sequences. The point is this: if your encrypt code encrypt
Re: Re: Re: hello everyone
Dear Ger Hobbelt, yes , you are correct , my client does not use Openssl code. abc_123_ok 2008-07-30 发件人： Ger Hobbelt 发送时间： 2008-07-28 18:10:31 收件人： openssl-users@openssl.org 抄送： 主题： Re: Re: Re: hello everyone > I use openssl as a server to test SSL client of our comany. the SSL client > is a part of embedded system。 > I used command as blow in Cygwin. From this I take it your embedded client does NOT use OpenSSL code, correct? -- Met vriendelijke groeten / Best regards, Ger Hobbelt
Re: Re: Re: hello everyone
Dear All, my problem can't still be sloved. abc_123_ok 2008-07-30 发件人： abc_123_ok 发送时间： 2008-07-29 14:52:06 收件人： openssl-users@openssl.org 抄送： 主题： Re: Re: Re: hello everyone Dear Ger Hobbelt and All, I should introduce a situation to you. I use openssl server and client to test with DES-CBC3-SHA. server show as following: $ openssl s_server -accept 443 -cert server_cert.pem -CAfile server_ca.pem -cip her DES-CBC3-SHA Enter pass phrase for server_cert.pem: Loading 'screen' into random state - done Using default temp DH parameters Using default temp ECDH parameters ACCEPT bad gethostbyaddr -BEGIN SSL SESSION PARAMETERS- MHUCAQECAgMBBAIACgQgzaEJiBUiqFiWXT+W7XIP5ARv+G4UuwfKED2Gu4TMKLEE MDWXUKokAf0it42BTyfP8X08fGfQYnL5SutZKBYQCOJW2rN6H0dLOYZR7oEQXaQB daEGAgRIjpfBogQCAgEspAYEBAE= -END SSL SESSION PARAMETERS- Shared ciphers:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3 -SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES 128-SHA:RC4-SHA:RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP- EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP- RC4-MD5 CIPHER is DES-CBC3-SHA d s client show as following: [EMAIL PROTECTED] ~]$ openssl s_client -connect 192.10.10.104:443 -cert client_cert.pem -CAfile client_ca.pem Enter pass phrase for client_cert.pem: CONNECTED(0003) depth=1 /C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] verify return:1 depth=0 /C=CN/ST=guangdong/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] verify return:1 --- Certificate chain 0 s:/C=CN/ST=guangdong/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] i:/C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] 1 s:/C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] i:/C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] --- Server certificate -BEGIN CERTIFICATE- MIIDpDCCAw2gAwIBAgIBATANBgkqhkiG9w0BAQQFADCBjjELMAkGA1UEBhMCQ04x EjAQBgNVBAgTCWd1YW5nZG9uZzERMA8GA1UEBxMIc2hlbnpoZW4xFDASBgNVBAoT C3NwZWN0cmF0ZWNoMQswCQYDVQQLEwJSRDENMAsGA1UEAxMEcXV6ZjEmMCQGCSqG SIb3DQEJARYXc3pfcXV6ZkBzcGVjdHJhdGVjaC5jb20wHhcNMDgwNzI0MDMwNTU1 WhcNMDkwNzI0MDMwNTU1WjB7MQswCQYDVQQGEwJDTjESMBAGA1UECBMJZ3Vhbmdk b25nMRQwEgYDVQQKEwtzcGVjdHJhdGVjaDELMAkGA1UECxMCUkQxDTALBgNVBAMT BHF1emYxJjAkBgkqhkiG9w0BCQEWF3N6X3F1emZAc3BlY3RyYXRlY2guY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCxZxJlk6W+mkBzzMW7E1uz5+du1oV8 dufTuNE4YGM52uWE/6PJOai84VGPx7SWQgFslEpQ5Zso1sAstvN4c+T2Xnw9VgR8 6H1Zy2YM3WT5ca35/K33Qm0wR4o5bdHcePrqbyWoZ7XTm6eW/1IMTBNrxHtywfMX KaDTVdeMNlPDHwIDAQABo4IBIjCCAR4wCQYDVR0TBAIwADAsBglghkgBhvhCAQ0E HxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFGGAhawP CJpMWw5QCvXcmFk6CTXqMIHDBgNVHSMEgbswgbiAFNlmSaexZ1HyCe4KZG1ymGPO ICx2oYGUpIGRMIGOMQswCQYDVQQGEwJDTjESMBAGA1UECBMJZ3Vhbmdkb25nMREw DwYDVQQHEwhzaGVuemhlbjEUMBIGA1UEChMLc3BlY3RyYXRlY2gxCzAJBgNVBAsT AlJEMQ0wCwYDVQQDEwRxdXpmMSYwJAYJKoZIhvcNAQkBFhdzel9xdXpmQHNwZWN0 cmF0ZWNoLmNvbYIJAMpTAf5ipB/0MA0GCSqGSIb3DQEBBAUAA4GBAEnxl5ax3rzW /oyE086XKuC+NGmzNlstsry8fFPhrA2qjVo4G+6c1nWt/0Cu98stq30u527AjdQK zcKm+wTK1df2zlCJiXdc8FsvRZ0MQ+1xMkbf8II4hJfUo0AH+w7ub3ebtkbb3q59 /6RfJEOiQ8lKwvqNiKDmH/xY0v30+mBw -END CERTIFICATE- subject=/C=CN/ST=guangdong/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] issuer=/C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED] --- No client certificate CA names sent --- SSL handshake has read 2012 bytes and written 332 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: DES-CBC3-SHA Session-ID: CDA109881522A858965D3F96ED720FE4046FF86E14BB07CA103D86BB84CC28B1 Session-ID-ctx: Master-Key: 359750AA2401FD22B78D814F27CFF17D3C7C67D06272F94AEB5928161008E256DAB37A1F474B398651EE81105DA40175 Key-Arg : None Krb5 Principal: None Start Time: 1217303619 Timeout : 300 (sec) Verify return code: 0 (ok) --- d s I use capture software catch the package as following: Secure Socket Layer TLSv1 Record Layer: Application Data Protocol: http Content Type: Application Data (23) Version: TLS 1.0 (0x0301) Length: 24 Encrypted Application Data: 83A774CFF8152C3975B7B846076398EC1439672ECE2E1D64 TLSv1 Record Layer: Application Data Protocol: http Content Type: Application Data (23) Version: TLS 1.0 (0x0301) Length: 32 Encrypted Application Data: 7C43BC0F546596DCFEA5C85022615ACEA579A6708BEA7948... the package include two application data, the first is length=24, I don't know what the 24 bytes? My english is not very good. so I can't express my idea very well. thanks abc_123_ok 2008-07-29 发件人： Ger Hobbelt 发送时间： 2008-07-28 18:09:11 收件人： openssl-users@openssl.org 抄送： 主题： Re: Re: Re: hello everyone Couple of things to test/check next: up to now you
Re: Re: Re: hello everyone
thanks Ger Hobbelt and All, my question have been solved, thanks a lot. 2008-08-02 abc_123_ok 发件人： Ger Hobbelt 发送时间： 2008-07-30 16:52:00 收件人： openssl-users 抄送： 主题： Re: Re: Re: hello everyone > yes , you are correct , my client does not use Openssl code. Okay... Well, this significantly complicates matters as I assume you have either (a) written the embedded code from scratch, or (b) use a different third party library for that code. Where 'gut feeling' makes me bet on (a) here. Correct? Anyway. The SSL protocol is standardized, so the problem is not there, but your issues are /very/ likely due to subtle bugs and/or lacking features in implementing the protocol in the embedded code. Maybe an 'open door' but note that SSL is not only 'encrypting' your raw data, but also includes protocol messages to signal the other side (re-)authentication or other SSL-defined activity is required. One of those messages is #23 (decimal) which is 'application_data' (see RFC4346 and other relevant spec documents). Message #23 does not just contain the 'encrypted application data' as is, but includes extra stuff, depending on cipher suite and protocol version. CBC ciphers require an IV to start, so the first few bytes VERY PROBABLY are the IV being sent to the other side (since you use CBC). Within the same message #23 (see RFC4346 for TLS1: appendix A.1), you will find trailing data constituting the MAC and padding, which will easily account for 24 bytes. (SHA-1 MAC at 160bits = 20 bytes already; padding may be an 'arbitrary' length.) Before we dive into that a little deeper, have a look at the network data passed between an *OpenSSL* client and *OpenSSL* server, like the s_client/s_server example you showed a little before here: notice there that the 'user' gets to see the plaintext data *exactly* as typed on the other side, but when you look at the raw TCP packets sent up and down, the TCP 'data' (so anything beyond the TCP header in the network packet) will contain some /extra/ (mostly encrypted) data as well: that's the SSL protocol layer at work. (I refer to s_client + s_server here, because you can quickly see those two 'work together fine'. This is very complex stuff so we try to go down one level at a time.) Your network sniffer apparently is able to decode the protocol sufficiently to show you the individual SSL protocol messages as I see SSL protocol message (23) explicitly mentioned there. However, NEVER think 'application data' == "my encrypted data and that's all"! Like I said, there's the IV, MAC and padding in there. And if you really want/need to travel all seven levels of Dante's Hell, you may wish to read the full SSL/TLS specification and then have a look at the actual SSL implementation of OpenSSL. Excellent work in my opinion, but like anything concerning cryptography, there's additional tweaks in there for security issues found by researchers after the specifications were cast in RFC rock. For a prime example of such, may I point you to the source code of [ssl/s3_pkt.c] and that includes reading the text available at the /~bodo/ URL mentioned in the comments there. Again, note that the code may be initially hard to read, but that wasn't done for 'fun' but because you need to watch out for a zillion things all at the same time. Generally speaking, I've found that one of the things to quickly break not-so-well-done SSL protocol implementations is having your [OpenSSL] implementation send an enforced 'cipher suit change' / 'renegotiation' message (and 'issue' which would otherwise only be reported for 'long transfers' due to internal SSL renegotiate timeout being triggered). You can try one example of this sort of neckbreaker by running s_client and typing a lone 'R' on a line (that's typing [Enter], [R], [Enter]). Hell, that breaks most 'overly naive' application code using OpenSSL -- which is /not/ a problem with OpenSSL or SSL itself, but rather programmers who cut&paste example code and don't check up on specs nor test beyond the 'It Just Works Now(tm)' stage, but I digress here. Returning to your encrypted 'application data' chunks: as described in the tls-cbc.txt (see URL in s3_pkt.c), the data not only contains your encrypted plaintext, but also IV, MAC, padding and possibly extra (zero length plaintext) data -- at least if I have interpreted the tls-cbc.txt, the source code and the protocol correctly. (If I made any mistake here, please correct me!) Besides, SSL is allowed to fragment / bundle your data in more or fewer application_data(23) messages as it deems necessary. (A process somewhat comparable to packet fragmentation on the IP and physical network layers for non-encrypted network communication protocols.) You may find t
Re: Re: Re: hello everyone
Dear Ger, ^_^ the reason is I didn't decrypt the 24 bytes data, so the IV don't update , as a result is the data decrypted is error. thanks a lot. abc_123_ok 2008-08-04 发件人： Ger Hobbelt 发送时间： 2008-08-04 17:08:38 收件人： openssl-users@openssl.org 抄送： 主题： Re: Re: Re: hello everyone Great! I'm curious: what was the solution? Thanks, Ger On Sat, Aug 2, 2008 at 10:12 AM, abc_123_ok <[EMAIL PROTECTED] > wrote: > thanks Ger Hobbelt and All, > > my question have been solved, > > thanks a lot. > 2008-08-02 > ____ > abc_123_ok > > 发件人： Ger Hobbelt > 发送时间： 2008-07-30 16:52:00 > 收件人： openssl-users > 抄送： > 主题： Re: Re: Re: hello everyone > > yes , you are correct , my client does not use Openssl code. > Okay... Well, this significantly complicates matters as I assume you > have either (a) written the embedded code from scratch, or (b) use a > different third party library for that code. Where 'gut feeling' makes > me bet on (a) here. Correct? > Anyway. The SSL protocol is standardized, so the problem is not there, > but your issues are /very/ likely due to subtle bugs and/or lacking > features in implementing the protocol in the embedded code. > Maybe an 'open door' but note that SSL is not only 'encrypting' your > raw data, but also includes protocol messages to signal the other side > (re-)authentication or other SSL-defined activity is required. One of > those messages is #23 (decimal) which is 'application_data' (see > RFC4346 and other relevant spec documents). > Message #23 does not just contain the 'encrypted application data' as > is, but includes extra stuff, depending on cipher suite and protocol > version. CBC ciphers require an IV to start, so the first few bytes > VERY PROBABLY are the IV being sent to the other side (since you use > CBC). Within the same message #23 (see RFC4346 for TLS1: appendix > A.1), you will find trailing data constituting the MAC and padding, > which will easily account for 24 bytes. (SHA-1 MAC at 160bits = 20 > bytes already; padding may be an 'arbitrary' length.) > Before we dive into that a little deeper, have a look at the network > data passed between an *OpenSSL* client and *OpenSSL* server, like the > s_client/s_server example you showed a little before here: notice > there that the 'user' gets to see the plaintext data *exactly* as > typed on the other side, but when you look at the raw TCP packets sent > up and down, the TCP 'data' (so anything beyond the TCP header in the > network packet) will contain some /extra/ (mostly encrypted) data as > well: that's the SSL protocol layer at work. (I refer to s_client + > s_server here, because you can quickly see those two 'work together > fine'. This is very complex stuff so we try to go down one level at a > time.) Your network sniffer apparently is able to decode the protocol > sufficiently to show you the individual SSL protocol messages as I see > SSL protocol message (23) explicitly mentioned there. > However, NEVER think 'application data' == "my encrypted data and that's all"! > Like I said, there's the IV, MAC and padding in there. And if you > really want/need to travel all seven levels of Dante's Hell, you may > wish to read the full SSL/TLS specification and then have a look at > the actual SSL implementation of OpenSSL. Excellent work in my > opinion, but like anything concerning cryptography, there's additional > tweaks in there for security issues found by researchers after the > specifications were cast in RFC rock. For a prime example of such, may > I point you to the source code of [ssl/s3_pkt.c] and that includes > reading the text available at the /~bodo/ URL mentioned in the > comments there. > Again, note that the code may be initially hard to read, but that > wasn't done for 'fun' but because you need to watch out for a zillion > things all at the same time. > > Generally speaking, I've found that one of the things to quickly break > not-so-well-done SSL protocol implementations is having your [OpenSSL] > implementation send an enforced 'cipher suit change' / 'renegotiation' > message (and 'issue' which would otherwise only be reported for 'long > transfers' due to internal SSL renegotiate timeout being triggered). > You can try one example of this sort of neckbreaker by running > s_client and typing a lone 'R' on a line (that's typing [Enter], [R], > [Enter]). Hell, that breaks most 'overly naive' application code using > OpenSSL -- which is /not/ a problem with OpenSSL or
NIST SP 800-22
Dear All,
In my program, I use rand() to generate some randsom, I use IAR compiler to
compile my program, I want to know the rand() of IAR lib if it is according to
NIST SP 800-22.
for (count = 0; count < 32; count++)
{
sslContext[0].clientRandom[count] = rand();
sslContext[0].sessionID[count] = rand();
}
Thanks & Best Regards.
