Folder collections, local server, ssl

[Başar Alabay]

I occasionally use alpine to check my mails from my hosters imap
account. That works. For that account I also have a folder collection,
that works, too. Though alpine often claims while starting up, that it
cannot find folder x, folder y etc. But later on, it seems to find them.

But I also had a folder collection with folders on my local imap server.
I think I remember that this worked for years, but recently there was a
big change in ssl and ssh. Maybe (?) after this backup the connection to
my localhost seems not to work anymore.

imap.somethingofficial.test/ssl/user=ma...@server.test (faked) worked and
works, but localhost/novalidate-cert/ssl/user=localuser (only faked
user) does not. I tried localhost/novalidate-cert/secure/user=localuser,
and that doesn’t work either. No route to host. Just tested … sending
does not work either. And this worked for yeras. Now it says SSL
negotiation failed. Using OpenSSH_8.8p1, OpenSSL 3.0.1 14 Dec 2021. What
could be the problem?

B. Alabay

[Eduardo Chappa]

On Fri, 21 Jan 2022, Başar Alabay wrote:

> imap.somethingofficial.test/ssl/user=ma...@server.test (faked) worked and
> works, but localhost/novalidate-cert/ssl/user=localuser (only faked
> user) does not.

Are you running Alpine in a unix/linux machine?

If so, what is the output of the command

openssl s_client -connect localhost:993 -crlf

--
Eduardo
https://tinyurl.com/yc377wlh (web)
http://repo.or.cz/alpine.git (Git)

[Başar Alabay]

Eduardo Chappa wrote:

> On Fri, 21 Jan 2022, Başar Alabay wrote:
>
>> imap.somethingofficial.test/ssl/user=ma...@server.test (faked) worked and
>> works, but localhost/novalidate-cert/ssl/user=localuser (only faked
>> user) does not.
>
> Are you running Alpine in a unix/linux machine?
>
> If so, what is the output of the command
>
> openssl s_client -connect localhost:993 -crlf

Lots of informations, and this:

verify error:num=18:self-signed certificate
verify return:1

00B02374FF7F0000:error:0A0C0103:SSL
routines:tls_process_key_exchange:internal
error:ssl/statem/statem_clnt.c:2247:

Verification error: self-signed certificate

B. Alabay

[Eduardo Chappa]

On Mon, 24 Jan 2022, Başar Alabay wrote:

>> Are you running Alpine in a unix/linux machine?
>>
>> If so, what is the output of the command
>>
>> openssl s_client -connect localhost:993 -crlf
>
> Lots of informations, and this:
>
> verify error:num=18:self-signed certificate verify return:1
>
> 00B02374FF7F0000:error:0A0C0103:SSL
> routines:tls_process_key_exchange:internal
> error:ssl/statem/statem_clnt.c:2247:
>
> Verification error: self-signed certificate

The error that you are seeing in Alpine is not this. The error you are
seeing in Alpine is that you are not connected to the internet. What is
the result of running the command

uname -n

in your system, and what happens when you use the value given by that
command instead of "localhost" (assuming these values are different)

[Başar Alabay]

Eduardo Chappa wrote:

> [-- text/plain, Encoding quoted-printable, Zeichensatz: UTF-8, 31 Zeilen --]

>
> On Mon, 24 Jan 2022, Başar Alabay wrote:
>
>>> Are you running Alpine in a unix/linux machine?
>>>
>>> If so, what is the output of the command
>>>
>>> openssl s_client -connect localhost:993 -crlf
>>
>> Lots of informations, and this:
>>
>> verify error:num=18:self-signed certificate verify return:1
>>
>> 00B02374FF7F0000:error:0A0C0103:SSL
>> routines:tls_process_key_exchange:internal
>> error:ssl/statem/statem_clnt.c:2247:
>>
>> Verification error: self-signed certificate
>
> The error that you are seeing in Alpine is not this. The error you are
> seeing in Alpine is that you are not connected to the internet. What is
> the result of running the command
>
> uname -n

Then I see a hostname that is internal.

> in your system, and what happens when you use the value given by that
> command instead of "localhost" (assuming these values are different)

Oh, I don’t think that this would work, because it never was intended to
reach the machine via outside. Usually I can reach everything with
localhost or the lan name of the machine. This worked with alpie, too. I
don’t know if an update of alpine broke that or an update of ssh/ssl.

B. Alabay

[Başar Alabay]

Başar Alabay wrote:

>> uname -n
>
> Then I see a hostname that is internal.
>
>> in your system, and what happens when you use the value given by that
>> command instead of "localhost" (assuming these values are different)
>
> Oh, I don’t think that this would work, because it never was intended to
> reach the machine via outside. Usually I can reach everything with
> localhost or the lan name of the machine. This worked with alpie, too. I
> don’t know if an update of alpine broke that or an update of ssh/ssl.

Nevertheless I tried that – uname -n gives a router given name. The same
happens: Alpines UI gets overwritten by the statement that the
authenticity of the host can't be established … the host key is known by
the following other name/address localhost, continue connecting
yes/no/fingerprint. This is overwriting, so I cannot react.

B. Alabay

[Başar Alabay]

I’ve made a manual ssh … so this is done. And now alpine says again
connection failed to xyz,143: connection refused.

xyz is faked.

B. Alabay

[Eduardo Chappa]

I am confused. Originally you said that the error was "no route to host"
which is an error that is given when you do not have an internet
connection. Now the error is different, and it is about a self-signed
certificate, wich was also given to you by openssl. In order to avoid this
error you can add /novalidate-cert to the definition of your server.

[Eduardo Chappa]

On Tue, 25 Jan 2022, Başar Alabay wrote:

> I’ve made a manual ssh … so this is done. And now alpine says again
> connection failed to xyz,143: connection refused.
>
> xyz is faked.

the "connection refused" error means that the server that you are trying
to connect is not listening in port 143. Maybe these errors can be
explained by a configuration of your router that is not forwarding this
connections to the correct computer that is actually listening in that
port.

[Başar Alabay]

Eduardo Chappa wrote:

> [-- text/plain, Encoding quoted-printable, Zeichensatz: UTF-8, 19 Zeilen --]

>
> On Tue, 25 Jan 2022, Başar Alabay wrote:
>
>> I’ve made a manual ssh … so this is done. And now alpine says again
>> connection failed to xyz,143: connection refused.
>>
>> xyz is faked.
>
> the "connection refused" error means that the server that you are trying
> to connect is not listening in port 143. Maybe these errors can be
> explained by a configuration of your router that is not forwarding this
> connections to the correct computer that is actually listening in that
> port.

Hm, all this is local on the machine. I thought, localhost does not make
the loop via the whole network?

B. Alabay

[Başar Alabay]

Eduardo Chappa wrote:

>> Nevertheless I tried that – uname -n gives a router given name. The same
>> happens: Alpines UI gets overwritten by the statement that the
>> authenticity of the host can't be established … the host key is known by
>> the following other name/address localhost, continue connecting
>> yes/no/fingerprint. This is overwriting, so I cannot react.
>
> I am confused. Originally you said that the error was "no route to host"
> which is an error that is given when you do not have an internet
> connection. Now the error is different, and it is about a self-signed
> certificate, wich was also given to you by openssl. In order to avoid this
> error you can add /novalidate-cert to the definition of your server.

That was included, all the years through:

name.of.machine/novalidate-cert/secure/user=name

name.of.machine was localhost in the beginning. And secure was ssl or
tls, I fotgot that, the years before.

Mail.app can connect to the local (dovecot) server.

B. Alabay

[Eduardo Chappa]

On Wed, 26 Jan 2022, Başar Alabay wrote:

> That was included, all the years through:
>
> name.of.machine/novalidate-cert/secure/user=name

/secure does not do what you think it does. Try /ssl or /tls as
appropriate.

[Başar Alabay]

Eduardo Chappa wrote:

> [-- text/plain, Encoding quoted-printable, Zeichensatz: UTF-8, 13 Zeilen --]

>
> On Wed, 26 Jan 2022, Başar Alabay wrote:
>
>> That was included, all the years through:
>>
>> name.of.machine/novalidate-cert/secure/user=name
>
> /secure does not do what you think it does. Try /ssl or /tls as
> appropriate.

/ssl gives a big note, that this will not work, I shall use /notls. With
/notls Alpine can't connect and has (again) this overwriting asking for
a password. And with /tls connection refused. Very, very strange. This
was not this way before.

B. Alabay

[Eduardo Chappa]

On Thu, 27 Jan 2022, Başar Alabay wrote:

> /ssl gives a big note, that this will not work, I shall use /notls. With
> /notls Alpine can't connect and has (again) this overwriting asking for
> a password. And with /tls connection refused. Very, very strange. This
> was not this way before.

One way in which the openssl could be failing is that your server and
Alpine support different encryption protocols. Try seeing if compiling
Alpine by yourself solves the problem, or if upgrading your dovecot will
help.

In regards to "overwriting asking for a password" i am not sure exactly
what you mean. My interpretation of that is that Alpine is trying rsh and
this is failing. This is typically because there is an error in a .login
file (~/.bashrc maybe?) and when an error is found the password is
requested (one way to test this is to simply rename the ~/.bashrc file and
see if asking for a password goes away. If that is the case, work in
fixing your ~/.bashrc file.)

Finally, as I implied before, you have to open port 143 if you want to use
/tls. Otherwise the connection will be refused.

[Başar Alabay]

Eduardo Chappa wrote:

> [-- text/plain, Encoding quoted-printable, Zeichensatz: ISO-8859-2, 32 Zeilen --]

>
> On Thu, 27 Jan 2022, Başar Alabay wrote:
>
>> /ssl gives a big note, that this will not work, I shall use /notls. With
>> /notls Alpine can't connect and has (again) this overwriting asking for
>> a password. And with /tls connection refused. Very, very strange. This
>> was not this way before.
>
> One way in which the openssl could be failing is that your server and
> Alpine support different encryption protocols. Try seeing if compiling
> Alpine by yourself solves the problem, or if upgrading your dovecot will
> help.

My dovecot ist part of Cutedge, so I can’t update that. It’s a server
package. Alpine is taken from Macports. Is that self compiling enough?

> In regards to "overwriting asking for a password" i am not sure exactly
> what you mean. My interpretation of that is that Alpine is trying rsh and
> this is failing. This is typically because there is an error in a .login
> file (~/.bashrc maybe?) and when an error is found the password is
> requested (one way to test this is to simply rename the ~/.bashrc file and
> see if asking for a password goes away. If that is the case, work in
> fixing your ~/.bashrc file.)

I use zsh with oh-my-zsh. With »overwriting« I mean, that it is like
a draw error – alpine gets overdrawn with the prompt, but I cannot type
anything. I’ve never seen that before.

> Finally, as I implied before, you have to open port 143 if you want to use
> /tls. Otherwise the connection will be refused.

Where do I have to open that? Alpine runs locally on the machine where
it shall open the folders with the password of the user. All this worked
before, I didn’t change anything … except ssh/ssl updates and alpine
updates. Nothing was opened, nothing closed?!

B. Alabay

[Eduardo Chappa]

On Fri, 28 Jan 2022, Başar Alabay wrote:

> My dovecot ist part of Cutedge, so I can’t update that. It’s a server
> package. Alpine is taken from Macports. Is that self compiling enough?

I have no idea. The point I am trying to make is that if you do not
control this, you can get into trouble. I do not know what versions of
openssl were used to compile your software. I do not know if you have a
configuration file for openssl that is involved here, and in general I do
not know much about your system. All I know is that you have a mac, with
no idea of what version you are running, or versions of the software that
is being run there. You can ignore my previous comment and reply with
generic answers like the one above, but all I can tell you is that you are
addressing the issue by not investigating. I am telling what to look at,
please take a deep look into that.

> I use zsh with oh-my-zsh. With »overwriting« I mean, that it is like a
> draw error – alpine gets overdrawn with the prompt, but I cannot type
> anything. I’ve never seen that before.

So, as I said, investigate the ".login" file that the zsh shell has. I do
not use zsh, or know what is the default. All I can tell you is what I
think you should investigate, but I cannot investigate it for you in your
system.

> Where do I have to open that? Alpine runs locally on the machine where
> it shall open the folders with the password of the user. All this worked
> before, I didn’t change anything … except ssh/ssl updates and alpine
> updates. Nothing was opened, nothing closed?!

Since I do not own a mac, I do not know the answer to that so I would
suggest you ask that question in a list that is appropriate for that,
unless someone here knows how to do that and wants to tell us how to do
that. Otherwise, there is always a search engine that might answer that
question for you.

Have fun investigating!