| Age | Commit message (Collapse) | Author |
|---|
|
When a positive non-zero value is returned from SSL_read or SSL_write,
there is data read or written, so there is no need to check for errors.
Only in the case the return value is 0 or negative.
|
|
It may be returned when the server closes the connection, see:
https://www.openssl.org/docs/manmaster/man3/SSL_get_error.html
We simply handle it as if there was no error and return zero bytes read.
Fixes: https://github.com/dillo-browser/dillo/issues/175
|
|
It would be nice if X509_ALGOR could be made opaque at some point.
There is a somewhat clumsy accessor X509_ALGOR_get0() that allows
obtaining the ASN1_OBJECT sitting inside an X509_ALGOR. Use this
instead.
|
|
In Mbed TLS 3.6.0 there is support for TLSv1.3 but it requires
special handling, so for now we disable it.
See: https://gitlab.alpinelinux.org/alpine/aports/-/commit/4dc36afaa81a4d73758b29fa77981d07dbae0080.patch
Fixes: https://github.com/dillo-browser/dillo/issues/158
|
|
|
|
The function SSL_get_peer_certificate() is deprecated in 3.0.0, but
still defined as a compatibility macro.
Fixes: https://github.com/dillo-browser/dillo/issues/118
|
|
|
|
|
|
We cannot rely on the return value and the errno, the function
SSL_get_error() must be used to determine what happen and if we need to
retry again. A wrapper function translates the SSL error into a proper
errno value.
In the case a premature EOF is sent by the server, the error queue is
emptied before the error is returned.
Fixes: https://github.com/dillo-browser/dillo/issues/79
|
|
As this is the page that new users will see for the first time, we want
to show them a very simple introduction so they can reach the full help
when they need it.
|
|
They may accidentally happen if a fd callback is still attached to the
connection socket while we wait in a FTLK dialog, causing another call
to Tls_connect() which will end up in an infinite loop.
|
|
Avoids calling the callback while the TLS dialog is opened, which was
causing and infinite loop of recursive calls to Tls_connect().
Fixes: https://github.com/dillo-browser/dillo/issues/49
|
|
Instead of just assert that there are no previous TLS errors, print the
error queue and then abort. It prevents the error queue to be emptied
before having a chance to see what error was stored.
|
|
More data will be written in the SSL_Shutdown() of TLS connections,
which causes errors if the file descriptor is closed. In particular,
LibreSSL will trigger an assert.
Fixes: https://github.com/dillo-browser/dillo/issues/51
|
|
The macro hides a return path and makes it more difficult to read the
condition as it is negated.
|
|
|
|
The website is now at https://dillo-browser.github.io/ and the
repository at https://github.com/dillo-browser/dillo.
|
|
|
|
Before OpenSSL 3.0, the EVP_PKEY_get_id() was named EVP_PKEY_id().
|
|
The SSLv23_client_method() function is deprecated:
https://www.openssl.org/docs/man3.2/man3/SSLv23_client_method.html
|
|
Brings the previous OpenSSL implementation into src/IO/tls_openssl.c.
Now, the TLS functions have the implementation name as prefix, like
a_Tls_openssl_connect().
The generic interface at IO/tls.h hides the implementation which is
selected at configure time. The appropriate functions of that
implementation are called from IO/tls.c to IO/tls_<impl>.c. In this way,
support for more TLS libraries can easily be added.
In the case of mbedTLS, there are some incompatible changes from version
2 to 3, so we use some ifdefs to fix the differences.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The handshake stuff should be named handshake. What should you call
initialize/setup plus handshake, then? I don't know, but 'connect'
for now, anyway.
|
|
as mentioned in the previous commit msg
|
|
Johannes reported that mbed TLS didn't like the connect() to be ongoing
still when the tls handshake was started on osx or dragonfly.
For an earlier version of the fix (which failed), it was basically free
to iterate through the IP address list upon connect() failure, so that
was implemented, and now I'm artificially breaking this patch into two
pieces to commit that separately.
|
|
You can trust an intermediate certificate in a chain, so let's be careful
with words here. It would of course be better to tell the user which
certificate was trusted in that case, but my understanding is that I would
have to go through each certificate in the chain and try to match it against
all of the trusted certificates, like mbed tls's verification code does in
the first place. This would involve a lot of digging around in mbed tls's
structures and using resources...
|
|
|
|
|
|
algorithms
|
|
|
|
|
|
reported by Nick Warne http://lists.dillo.org/pipermail/dillo-dev/2016-July/010941.html
checking mbedtls/ssl.h usability... no
checking mbedtls/ssl.h presence... yes
configure: WARNING: mbedtls/ssl.h: present but cannot be compiled
configure: WARNING: mbedtls/ssl.h: check for missing prerequisite headers?
configure: WARNING: mbedtls/ssl.h: see the Autoconf documentation
configure: WARNING: mbedtls/ssl.h: section "Present But Cannot Be Compiled"
configure: WARNING: mbedtls/ssl.h: proceeding with the compiler's result checking for mbedtls/ssl.h... no
configure: WARNING: *** mbed TLS 2 not found. Disabling SSL/HTTPS/TLS support. ***
|
|
|
|
|
|
|
|
|
|
|
|
a status message
|
|
|
|
thread begins here:
http://lists.dillo.org/pipermail/dillo-dev/2016-February/010682.html
|
|
I never knew that if you give it a small string to copy into a big buffer,
it'll waste time filling the rest of it with '\0'.
|
|
|
|
|
|
|
|
|
