The whole Finish message, (ie., Handshake protocols Header indicating
this message as Finished message, and the encrypted Data) is encrypted
and sent.
At the other end the packet is decrypted. This decryption is done
because a Change Cipher Spec message has been received before this
message by the other end.
After decrypting the received message, it finds the expected Finished
message, and verifies the data sent in the Finished message.
-- Lakshmi Prasanna
On Tue, Jun 17, 2008 at 6:51 PM, Vijay Kotari <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I do know for a fact that part of the Finish message is encrypted. My
> question was actually if the Message type field is also part of the
> encrypted part? In which case, as I had pointed out earlier, there is a
> chance that the first byte of the encrypted {message_type + message} can be
> equal to one of the Standard Message types hence misleading the client to
> the type of packet that is actually being sent. To put it another way, IMHO,
> it does not make sense to have a field in a packet whose value does not give
> us any information of the packet itself. i.e. if the field contains 14 (in
> base 10), should it be interpreted as a Finish packet with encrypted data
> whose first byte also happens to be 14 or a ServerHelloDone packet?
>
>
> Regards,
> Vijay K.
>
> On Tue, Jun 17, 2008 at 6:32 PM, <[EMAIL PROTECTED]> wrote:
>>
>> Hello,
>>
>> [EMAIL PROTECTED] wrote on 06/17/2008 02:11:14 PM:
>>
>> > Yup, that solves it.
>> >
>> > Another matter that's been troubling me is the output that I get when I
>> run the s_server
>> > program with the debug option. At the end of the handshake, when the
>> server sends the
>> > Finished Packet to the client, the following packet dump is obtained.
>> >
>> > write to 099EB570 [099FADC0] (53 bytes => 53 (0x35))
>> > 0000 - 16 03 01 00 30 b8 bd 82-61 05 3c 59 0e 0e cc 0b
>> > 0010 - 57 88 ad f2 93 1e 5a 1f -9f d1 82 3a 10 e2 4b d3
>> > 0020 - 00 f4 91 7d f1 10 a2 1d-d4 e6 ef 2a c6 be 1e b5
>> > 0030 - 16 fd f6 09 71
>> >
>> > Byte 0x00 -> 0x16 is indicative of the Handshake protocol in progress.
>> > Byte 0x01 and 0x02 -> SSL v.3.1
>> > Byte 0x03 and 0x04 -> Length of message that follows, 48 bytes + the 5
>> before it, totals
>> > to the 53 bytes shown at the very beginning.
>> > Byte 0x05 -> This is where the trouble begins. It shows 0xb8 which does
>> not correspond
>> > to any standard message type. It should, in my opinion show, 0x14 which
>> is the message
>> > type for the Finished packet. I ran the same program a few times I keep
>> getting what
>> > appears to me as random bytes each time. When I run the s_server program
>> with both the
>> > msg and debug options, the output from the msg tallies with my
>> observation above. I was
>> > not sure if the actual packet contents that were being sent as both the
>> msg and debug
>> > option seemed to contradict each other.
>> >
>> > I then wrote a sniffer to check the actual packet contents and they
>> corresponded to
>> > those received from debug mode which now leads to me believe this ->
>> That, in the
>> > "Finish" packet, the message type, message length and the handshake
>> message are all
>> > encrypted. Am I right in thinking so? In which case, I wonder, if the
>> client were to
>> > receive such a packet, which coincedentally were to have its Byte 0x05
>> as some standard
>> > message type, will it not proceed to treat that packet correspondingly
>> instead of
>> > treating it as a Finished packet? Taking this even further, the whole
>> idea of having 20
>> > as a standard message type for a finished packet would be useless.
>> >
>> > I realise that the above is a pretty lengthy description of the problem
>> that I am facing
>> > and will be more than happy to elaborate on any part of it that is
>> ambigous. I am
>> > obviously wrong somewhere and it would be great if someone can point
>> where exactly.
>> Finished packet is the first packet with encrypted contents.
>> If you look at packets dump, you will see ChangeCipherSpec packet Finished
>> packet.
>> All packet after ChangeCipherSpec should use encryption, this is something
>> like switch witch turn on encryption.
>> So, Finished packet should be decrypted before analysed.
>>
>> Best regards,
>> --
>> Marek Marcola <[EMAIL PROTECTED]>
>>
>> ______________________________________________________________________
>> OpenSSL Project http://www.openssl.org
>> User Support Mailing List openssl-users@openssl.org
>> Automated List Manager [EMAIL PROTECTED]
>
>
--
thanks,
Lakshmi Prasanna
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
