메모리 BIO 인터페이스를 사용하여 SCTP 스트림을 통해 TLS 용 EAGAIN 케이스를 처리하는 방법

Question

BIO 메모리 인터페이스를 사용하여 SCTP를 통해 TLS를 구현했습니다.

그래서 클라이언트 측에서, 애플리케이션 데이터를 전송하는 동안

1. SSL_write() API는 데이터를 암호화 및 관련된 기록 BIO 인터페이스에 데이터를 기록한다.
2. 이어서 BIO 인터페이스로부터 데이터 BIO_read() 호출하고
3. sctp_sendmsg()는 API를 사용하여 소켓에 발송을 사용하여 출력 버퍼에 판독된다.
4. BIO_write() API는 판독 BIO 버퍼에 기록
   1. sctp_recvmsg() API는 소켓으로부터 ecrypted 메시지 청크를 판독 소켓으로부터 데이터를 판독하는 동안, 서버 측에서 마찬가지로

, 및
5. SSL_read() api는 BIO에서 읽은 데이터를 해독합니다.

내가 관심이있는 부분은 클라이언트 측에서 1 단계와 2 단계가 완료되고 3 단계에서 소켓에서 EAGAIN을 얻는 것입니다. 따라서 BIO 버퍼에서 읽은 데이터가 무엇이든간에 정리하고 응용 프로그램에 잠시 후 데이터를 다시 보내달라고 요청하십시오.

이제 클라이언트 측에서 1, 2, 3 단계가 진행될 때 서버 측에서 openssl이받은 레코드에 bad_record_mac가 있고 연결이 닫히는 것을 찾습니다.

Google 검색에서 나는 MAC 인코딩이 인코딩 된 이전 패킷에 대한 의존성을 가지고 있기 때문에 TLS 패킷이 순서가 벗어나는 경우가 발생할 수 있다는 것을 알게되었습니다. TLS는 동일한 순서로 전달 된 패킷을 가져야합니다 . 그래서 내가 EAGAIN에 대한 데이터를 정리할 때 나는 SSL 패킷을 버린 다음 순서가 다른 다음 패킷을 보냈습니다 (여기에 선명도가 없습니다)?

소켓이 EAGAIN을 반환 할 때마다 소켓을 쓸 수있을 때까지 무한 대기하도록 코드를 변경 한 다음 모든 것이 잘되고 서버 측에서 bad_record_mac가 표시되지 않습니다.

누군가이 EAGAIN 처리에 관해 나를 도와 줄 수 있습니까? 문제를 해결하기 위해 무한한 시간을 할애 할 수는 없지만 다른 방법이 있습니까?

Answer 1

1. 쓰기 가능으로 선택하십시오.
2. 보내기를 반복하십시오.
3. 보내기가 완료되지 않은 경우 보낸 버퍼의 부분을 제거하고 (1)로 이동하십시오. 내가 BIO 버퍼에서 읽은 어떤 데이터 그래서

, 나는 이것이 무엇을 의미하는지 모르는

그것을 정리. 당신은 보내지 만,받지 못합니다.

그냥 소켓을 EAGAIN을 반환 할 때마다, 내가 소켓을 쓰기 한 후 모든 것이 잘 가고 난 서버 측에서 어떤 bad_record_mac를 참조 해달라고까지 무한 대기를 할 수있는 코드를 변경했다, 내 가설을 확인합니다.

그게 바로 당신이해야 할 일입니다. 나는 당신이 그 대신에 무엇을 할 수 있었는지 상상할 수 없으며 그것에 대한 당신의 묘사는 말이되지 않습니다.

Answer 2

... 소켓에서 EAGAIN을 가져옵니다. 따라서 BIO 버퍼에서 읽은 데이터가 무엇이든간에 정리하고 응용 프로그램에 잠시 후 데이터를 다시 보내달라고 요청하십시오. 당신이 소켓에 EAGAIN을받을 경우

나중에 같은 암호화 데이터를 보내려고합니다.

대신 암호화 된 데이터를 버리고 응용 프로그램에 동일한 일반 데이터를 다시 보내도록 요청하는 것입니다. 즉,이 데이터는 다시 암호화됩니다. 그러나 SSL의 일반 데이터 암호화에는 SSL 프레임의 시퀀스 번호가 포함되어 있으며이 시퀀스 번호는 버린 마지막 SSL 프레임의 시퀀스 번호와 다릅니다.

따라서 전체 SSL 프레임을 버린 경우 예상 시퀀스 번호와 맞지 않는 다음 시퀀스 번호로 새 SSL 프레임을 보내려고합니다. 이전 SSL 프레임의 일부를 전송하고 나머지를 버린 경우 이전에 전송 한 새 데이터가 이전 프레임의 일부로 간주되므로 프레임의 HMAC가 일치하지 않습니다.

따라서 암호화 된 데이터는 버리지 말고 상위 데이터가 일반 데이터를 다시 보내지 않도록하려면 다시 보내보십시오.