{"action":"created","issue":{"url":"https://api.github.com/repos/openssl/openssl/issues/1903","repository_url":"https://api.github.com/repos/openssl/openssl","labels_url":"https://api.github.com/repos/openssl/openssl/issues/1903/labels{/name}","comments_url":"https://api.github.com/repos/openssl/openssl/issues/1903/comments","events_url":"https://api.github.com/repos/openssl/openssl/issues/1903/events","html_url":"https://github.com/openssl/openssl/issues/1903","id":188774913,"number":1903,"title":"Out of date/incorrect advice in SSL_get_error docs as of 1.1.0c","user":{"login":"sfackler","id":1455697,"avatar_url":"https://avatars.githubusercontent.com/u/1455697?v=3","gravatar_id":"","url":"https://api.github.com/users/sfackler","html_url":"https://github.com/sfackler","followers_url":"https://api.github.com/users/sfackler/followers","following_url":"https://api.github.com/users/sfackler/following{/other_user}","gists_url":"https://api.github.com/users/sfackler/gists{/gist_id}","starred_url":"https://api.github.com/users/sfackler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sfackler/subscriptions","organizations_url":"https://api.github.com/users/sfackler/orgs","repos_url":"https://api.github.com/users/sfackler/repos","events_url":"https://api.github.com/users/sfackler/events{/privacy}","received_events_url":"https://api.github.com/users/sfackler/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":30,"created_at":"2016-11-11T14:45:36Z","updated_at":"2016-12-06T17:26:46Z","closed_at":null,"body":"This commit changed `SSL_read` to return -1 rather than 0 when `BIO_read` returns 0: https://github.com/openssl/openssl/commit/4880672a9b41a09a0984b55e219f02a2de7ab75e, which landed in the 1.1.0c release.\r\n\r\nWhen `SSL_get_error` is called, it'll return `SSL_ERROR_SYSCALL`, and the error stack will be empty. The man page for `SSL_get_error` says that at that point you should check `SSL_read`'s return code; a -1 means that there was a read error and to consult the BIO-specific error (e.g. errno), and 0 means that there was an EOF in violation of the protocol, but that doesn't appear to be correct anymore.\r\n\r\nIs this a bug in the implementation or the docs? If the new implementation is correct, I guess the new procedure should be to check the BIO error, and check if an error actually occurred to determine if it's an EOF?"},"comment":{"url":"https://api.github.com/repos/openssl/openssl/issues/comments/265214096","html_url":"https://github.com/openssl/openssl/issues/1903#issuecomment-265214096","issue_url":"https://api.github.com/repos/openssl/openssl/issues/1903","id":265214096,"user":{"login":"mattcaswell","id":7422273,"avatar_url":"https://avatars.githubusercontent.com/u/7422273?v=3","gravatar_id":"","url":"https://api.github.com/users/mattcaswell","html_url":"https://github.com/mattcaswell","followers_url":"https://api.github.com/users/mattcaswell/followers","following_url":"https://api.github.com/users/mattcaswell/following{/other_user}","gists_url":"https://api.github.com/users/mattcaswell/gists{/gist_id}","starred_url":"https://api.github.com/users/mattcaswell/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mattcaswell/subscriptions","organizations_url":"https://api.github.com/users/mattcaswell/orgs","repos_url":"https://api.github.com/users/mattcaswell/repos","events_url":"https://api.github.com/users/mattcaswell/events{/privacy}","received_events_url":"https://api.github.com/users/mattcaswell/received_events","type":"User","site_admin":false},"created_at":"2016-12-06T17:26:46Z","updated_at":"2016-12-06T17:26:46Z","body":"> Suppose that after detecting a fatal alert (i.e., getting SSL_ERROR_SSL and SSL_get_shutdown() signaling SSL_RECEIVED_SHUTDOWN), I still call SSL_shutdown(). How problematic is this? You say \"you should not call SSL_shutdown() in this case\", and I can see that it would not make sense, but does it warrant the extra complexity to prevent calling SSL_shutdown() regardless in this situation?\r\n\r\nThe problem here is that as soon as OpenSSL hits a fatal error (for whatever reason), it immediately returns. This might mean that the internal state of the SSL object is not left in a consistent state. If you then start to try and do IO with it then you will get undefined results. In the worst case scenario that could lead to a crash. In most cases it will probably work. In that case, if you call SSL_shutdown(), it will send a close_notify - which just doesn't make sense. Arguably, we should prevent that, so it's not inconceivable that we might change that behaviour at some point. As a general rule though, don't try and continue to do IO on an SSL object that has returned SSL_ERROR_SSL (or for that matter one which has returned SSL_ERROR_SYSCALL).\r\n\r\n> Second, when I try to negotiate a connection, and I get a return value ≤0 from SSL_accept() or SSL_connect(), and further, I get SSL_ERROR_SYSCALL from SSL_get_error(), and ERR_get_error() returns 0, then the code I am maintaining assumes that EOF was unexpectedly encountered during negotiation. How safe is this assumption? Could this also be due to a different error? And conversely, could EOF also be reflected differently? In addition, what are the alternatives I have for distinguishing this case specifically (EOF during session negotiation). I suppose I could test both wbio and rbio for EOF with BIO_eof(), but that likewise does not seem completely reliable to me, because if either of them is no longer needed, then it could have been closed without error.\r\n\r\nIf you get SSL_ERROR_SYSCALL from SSL_get_error() it tells you is that there was a fatal non-retryable error in a system call. 99.9% of the time that is going to be because the peer closed the connection down. But even if it isn't, its a fatal non-retryable error so - effectively - the connection is closed, so I think it should be ok to treat it the same way."}}
{"actor":{"display_login":"mattcaswell"}}