|
Hi All, In dtls1_get_record(), we are calling ssl3_read_n to get 13 bytes of DTLS record header from socket and then based on the length in record header, we again call ssl3_read_n to get record payload from socket. Here we are handling invalid
record, like length less 13 bytes or invalid version in record header or invalid epoch etc. If such invalid record comes then we are dropping that record and going to read again from socket, by calling ssl3_read_n again. If a peer is continuously sending invalid
DTLS record, then our execution will be just running inside dtls1_get_record function. It wont come out of that function. So if a malicious peer wants to block our DTLS connection thread, then it can do by simply sending invalid DTLS record continuously. This
behaviour would be same for both synchronous and asynchronous UDP sockets. This will simply block the application for long time, for the API SSL_connect, SSL_accept or SSL_read. I feel here we should not block the application call for long time, we should have some mechanism to fail the connection and inform application if we get invalid DTLS record continuously. For example, if we receive around 100 invalid DTLS
record continuously, then we should come out of this "goto" in dtls1_get_record and return failure to application. And also we can send alert to peer and close the DTLS connection. For similar issue in ssl3_get_record(), we are having a max limit(MAX_EMPTY_RECORDS) for the received empty record. I feel similar limit should be there for invalid DTLS record in dtls1_get_record. Similarly in ssl3_get_message and dtls1_get_message_fragment, if we receive Hello request message continuously, then we are just dropping and continuously going back to read on socket. This also may cause a long time block to application,
for the API SSL_connect if malicious peer is continuously sending Hello request msg. I feel blocking of application call for a long time should be avoided. Please check this and clarify me, if my understanding is wrong.
Note : I am referring openssl-1.0.2k and asking this doubt. Regards, Ashok
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 |
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
