CODEWITHSUNDEEP
csockets
Rick
Rick

Reputation: 7506

What is premature close as for network programming?

I am reading An Introduction to OpenSSL Programming and here's code from Figure 6 

while(1){
    r=SSL_read(ssl,buf,BUFSIZZ);
    switch(SSL_get_error(ssl,r)){
        case SSL_ERROR_NONE:
            len=r;
            break;
        case SSL_ERROR_ZERO_RETURN:
            goto shutdown;
        case SSL_ERROR_SYSCALL:
            fprintf(stderr,
            "SSL Error: Premature close0");
            goto done;
        default:
            berr_exit("SSL read problem");
}
        fwrite(buf,1,len,stdout);
}

And underneath, in the Error Handling sections, it says:

Error Handling

If the return value was something negative then some kind of error occurred. There are two kinds of errors we’re concerned with: ordinary errors and "premature closes". We use the SSL_get_error() call to determine which kind of error we have. Error handling in our client is pretty primitive so with most errors we simply call berr_exit() to print an error message and exit. Premature closes have to be handled specially.

What is premature close? (I didn't find anything related on SO) Why here it's saying it need to be handled specially?

Upvotes: 1

Views: 1079

Answers (1)

paulsm4
paulsm4

Reputation: 121599

At the risk of oversimplifying:

  1. At the TCP/IP level, a TCP connection may be "closed gracefully" (both sides send a FIN to close their respective connections), or "terminated abruptly" (one side or another gets a RST). You can read more in RFC 783.

  2. SSL introduces additional protocols on top of TCP/IP.

  3. Older versions of SSL were vulnerable to "truncation attacks":

https://www.cs.cmu.edu/~srini/15-441/F02/Projects/lab01/reference/part1.pdf

TCP uses a FIN segment to indicate that the sender has sent all of its data. SSL version 2 simply allowed either side to send a TCP FIN to terminate the SSL connection. This allowed for a "truncation attack": the attacker could make it appear that a message was shorter than it was simply by forging a TCP FIN. Unless the victim had some other way of knowing what message length to expect it would simply believe that it had received a shorter message.

  1. SSLv3 introduced a "close_notify alert" to mitigate this potential security problem:

The close_notify is an SSL message (and therefore secured) but is not part of the data stream itself and so is not seen by the application. No data may be transmitted after the close_notify is sent.

Thus, when SSL_read() returns 0 to indicate that the socket has been closed, this really means that the close_notify has been received. If the client receives FIN before receiving a close_notify, SSL_read() will return with an error. This is called a "premature close".

  1. "Unfortunately", the article continues, "sending premature closes is a rather common error, particularly common with clients". They should be handled "differently" from other errors. Or perhaps sometimes even best ignored.

Here's another good link: https://stackoverflow.com/a/28056464/421195

Upvotes: 3

Related Questions