1 25674390: NNTP slot used by this thread: neodome Username ok1 [$0000250C][...]
3 25674390: Connecting to NNTP 127.0.0.1:55555 [$0000250C]
0 25675484: !Quit (Finished) [$0000250C][...]
5 25675484: Socket Error # 0; (neodome Username ok) (Finished) [$0000250C]
The line I don't understand is that the error is a Dialog "socket error". What's that?
1 25674390: NNTP slot used by this thread: neodome Username ok1 [$0000250C][...]
3 25674390: Connecting to NNTP 127.0.0.1:55555 [$0000250C]
0 25675484: !Quit (Finished) [$0000250C]
The line I don't understand is that the error is a Dialog "socket error". What's that?
In a minute I will try it again by removing that one line (verify = 0)
in the stunnel.conf file for Neodome, but does that look like to you
that the certificate for Neodome is having the problem?
A socket is a dedicated connection established by the OS between a program and an IP-address:port combination. Several such sockets can exist in parallel at any certain time, just not with the same parameters.
"Socket error # 0" isn't a normal Socket error number. It will be returned
by the Indy network functions (a Delphi network library used by Dialog),
when no connection could be established, at all.
From above information it seems, you set up your connection to the Neodome server inside Dialog to connect to localhost (127.0.0.1) on port 55555.
User name and password for the Neodome server have to be entered inside the Dialog connection settings, as well. You must /not/ tick on the SSL box, though, because with above parameters you most likely want to use a more up-to-date program for managing the encryption.
You are probably using sTunnel as an intermediate for encrypted connections. With above parameters you need to set up sTunnel to accept local connections from port 55555 and forward them encrypted to the Neodome NNTP server:
[Neodome]
client = yes
accept = localhost:55555
connect = news.neodome.net:563
verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.neodome.net
OCSPaia = yes
Please check, if sTunnel is running at all.
And if the connection parameters
are set correctly. (Especially, that no 2 connection sections using the same /internal/ port number [55555 in this case].) If this all seems okay, check the sTunnel log file for further information.
Are you using sTunnel, a VPN, or other local proxy with Dialog?
I thought Neodome died, so there'd be no NNTP server to which Dialog (or
your proxy) could connect.
Dialog log:
5 44896390: Socket Error # 0; (Neodome username ok) (Finished) [$0000220C]
0 44896390: KillNNTP entered for: Neodome username ok1 (Finished) [$0000220C]
Stunnel log:
2024.01.07 03:57:01 LOG5[0]: Service [Neodome] accepted connection from 127.0.0.1:55555
2024.01.07 03:57:01 LOG5[0]: s_connect: connected 95.216.243.224:563
2024.01.07 03:57:01 LOG5[0]: Service [Neodome] connected remote server from 192.168.1.23:55555
2024.01.07 03:57:01 LOG4[0]: CERT: Pre-verification error: self-signed certificate
2024.01.07 03:57:01 LOG4[0]: Rejected by CERT at depth=0: O=Neodome, CN=neodome.net, emailAddress=admin@neodome.net
2024.01.07 03:57:01 LOG3[0]: SSL_connect: ssl/statem/statem_clnt.c:1889: error:0A000086:SSL routines::certificate verify failed
2024.01.07 03:57:01 LOG5[0]: Connection closed/reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
The two main questions are what is a "KillNNTP" in Dialog and
does that error look like the certificate is bad for Neodome?
Is there a way to test the certificate for Neodome?
"certificate has expired"
Dialog is failing on a Neodome account setup that used to work.
Posting article failed: Socket Error # 0; (nameofserver username ok)(Finished)
Socket Error # 0; (nameofserver username ok)(Finished)
The stunnel.conf file has the same boilerplate setup as it always had.
That boilerplate stunnel.conf is this (which used to work for Neodome).
[neodome]
client = yes
accept = 127.0.0.1:55555
connect = news.neodome.net:563
verify = 0
verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.neodome.net
OCSPaia = yes
That same boilerplate stunnel.conf works for other encrypted servers.
Just not Neodome.
40TudeDialog is set up for that user as any other setup would be.
Host: 127.0.0.1
Port: 55555
SSL: unchecked
Username: abcdefg
Password: xxxxxxx
Allwd. conn.: 2
Use pipelining (unchecked)
I set the log level to "0 - All debug messages" by right clicking on "Connections" at the bottom right corner of the Windows Dialog GUI.
Then I copied the section of the files in Program Files under "logs".
0 25674390: Creating worker thread: Sending message to news.software.readers neodome Username ok1
0 25674390: FDATA: Opening 1
0 25674390: FDATA: Reading itemcount 3
0 25674390: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2572
3 25674390: Sending message to news.software.readers (Started) [$0000250C]
1 25674390: NNTP slot used by this thread: neodome Username ok1 [$0000250C]
3 25674390: Connecting to NNTP 127.0.0.1:60569 [$0000250C]
1 25675500: Reindexing (Order: 3, no filtering) of group 1 with 2574 articles took 16 ms
0 25675500: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2572
0 25675500: FDATA: Regular update PAK - ChangeCount: 0
0 25675500: FDATA: adding GroupKey: 1 ArticleKey: 2573
0 25675500: FDATA: Regular update PAK - ChangeCount: 1
0 25675515: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675515: FontFB: No non-ASCII characters found; Using default font
0 25675515: FontFB: Using font "Arial" which is missing 0 glyphs.
0 25675515: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675515: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675531: FontFB: No non-ASCII characters found; Using default font
0 25675531: FontFB: Using font "Arial" which is missing 0 glyphs.
0 25675531: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675531: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675531: FontFB: No non-ASCII characters found; Using default font
0 25675531: FontFB: Using font "Arial" which is missing 0 glyphs.
0 25675546: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675484: !Quit (Finished) [$0000250C]
5 25675484: Socket Error # 0; (neodome Username ok) (Finished) [$0000250C]
0 25675484: KillNNTP entered for: neodome Username ok1 (Finished) [$0000250C]
0 25675484: KillNNTP left for: neodome Username ok1 (Finished) [$0000250C]
0 25675484: KillNNTP entered for: neodome Username ok1 (Finished) [$0000250C]
0 25675484: KillNNTP left for: neodome Username ok1 (Finished) [$0000250C]
5 25675484: Posting article failed: Socket Error # 0; (neodome Username ok) (Finished) [$0000250C]
1 25675500: Sending message to news.software.readers (Finished) (Finished) [$0000250C]
0 25676328: TFlushBodiesThread started with ThreadID: $16A0
1 25678328: Flushing body db
0 25678328: FDATA: Updating PAK, number of subfiles: 29
0 25678328: FDATA: Writing itemcount 3
0 25678328: FDATA: Closing 1
1 25679687: Main window close query
1 25679750: Main window destroy called - Goodbye
0 25679765: FDATA: destroying; Changecount: 0
1 25679765: Flushing group and server list
How can I further debug this socket error before contacting Neodome admins? (What is a Dialog socket error anyway?)
On Sun, 7th Jan 2024 04:11:40 -0500, Ronald wrote:
Dialog log:
5 44896390: Socket Error # 0; (Neodome username ok) (Finished) [$0000220C] >> 0 44896390: KillNNTP entered for: Neodome username ok1 (Finished) [$0000220C]
Stunnel log:
2024.01.07 03:57:01 LOG5[0]: Service [Neodome] accepted connection from 127.0.0.1:55555
2024.01.07 03:57:01 LOG5[0]: s_connect: connected 95.216.243.224:563
2024.01.07 03:57:01 LOG5[0]: Service [Neodome] connected remote server from 192.168.1.23:55555
2024.01.07 03:57:01 LOG4[0]: CERT: Pre-verification error: self-signed certificate
2024.01.07 03:57:01 LOG4[0]: Rejected by CERT at depth=0: O=Neodome, CN=neodome.net, emailAddress=admin@neodome.net
2024.01.07 03:57:01 LOG3[0]: SSL_connect: ssl/statem/statem_clnt.c:1889: error:0A000086:SSL routines::certificate verify failed
2024.01.07 03:57:01 LOG5[0]: Connection closed/reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
The two main questions are what is a "KillNNTP" in Dialog and
Network connection socket is unregistered in the OS active connection table.
does that error look like the certificate is bad for Neodome?
Yes.
Is there a way to test the certificate for Neodome?
Yes, for instance with OpenSSL (https://www.openssl.org):
openssl.exe s_client -connect news.neodome.net:563
"certificate has expired"
If you don't care about valid certificates for your encrypted connection
you may use this shorted sTunnel configuration. It should still work.
[Neodome]
client = yes
accept = localhost:55555
connect = news.neodome.net:563
HTH.
Bernd
VanguardLH wrote:
Are you using sTunnel, a VPN, or other local proxy with Dialog?
I'm using VPN plus Stunnel with Dialog on Windows.
Just like everyone else does (as Dialog needs Stunned for port 563).
I thought Neodome died, so there'd be no NNTP server to which Dialog (or
your proxy) could connect.
The odd thing to me is it's supposedly a self-signed certificate.
I don't really know what that means, but how can it expire then?
echo q | openssl s_client -connect news.neodome.net:563 | openssl x509 -noout -enddate | findstr "notAfter"
It reported this result:
depth=0 O = Neodome, CN = neodome.net, emailAddress = admin@neodome.net
verify error:num=18:self signed certificate
verify return:1
depth=0 O = Neodome, CN = neodome.net, emailAddress = admin@neodome.net
verify error:num=10:certificate has expired
notAfter=Dec 31 21:59:46 2020 GMT
verify return:1
depth=0 O = Neodome, CN = neodome.net, emailAddress = admin@neodome.net
notAfter=Dec 31 21:59:46 2020 GMT
verify return:1
notAfter=Dec 31 21:59:46 2020 GMT
Is a login even required for news.neodome.net?
If you don't care about valid certificates for your encrypted connection
you may use this shorted sTunnel configuration. It should still work.
[Neodome]
client = yes
accept = localhost:55555
connect = news.neodome.net:563
Is a login even required for news.neodome.net?
AFAICT, for posting: yes, for reading: no.
I don't understand why I even need encryption
since (as Vanguard said) the end result is being posted to the public.
I think it's supposed to protect my login credentials
but isn't that what the VPN is for? I'm always on NordVPN all the time anyway.
[Neodome]
client = yes
accept = localhost:55555
connect = news.neodome.net:563
Oh my gosh. That actually worked! How did you know how to do that trick?
Stunnel log
2024.01.07 06:28:31 LOG5[1]: Service [Neodome] accepted connection from 127.0.0.1:43503
2024.01.07 06:28:32 LOG5[1]: s_connect: connected 95.216.243.224:563
2024.01.07 06:28:32 LOG5[1]: Service [Neodome] connected remote server from 10.211.1.153:43504
2024.01.07 06:28:51 LOG5[1]: Connection closed: 344 byte(s) sent to TLS, 320 byte(s) sent to socket
Dialog log
3 53998687: Posting message to NNTP server [$00000634]
1 54004625: Reindexing (Order: 3, no filtering) of group 2 with 8910 articles took 47 ms
3 54004562: Posting sent successfully: Article received <###########@neodome.net>; (Finished) [$00000634]
Can you give me a clue as to what that Stunnel log did?
Somehow it still posted WITHOUT needing the certificate to be valid.
Will that method work with all encrypted news servers?
With Neodome, their NNTP server seems to be nearly abandoned. Therefore, contacting the admins will probably not lead to a fixed certificate.
Can you give me a clue as to what that Stunnel log did?
Somehow it still posted WITHOUT needing the certificate to be valid.
Encryption doesn't need a certificate to be valid. This way, you just can't be sure, that the target server really /is/ the one you are trying to
connect to. It might be an unfriendly server /impersonating/ the other one.
Does that mean I could have omitted stunnel altogether and just used the 40tude dialog user setup with "Host = news.neodome.net" & "Port = 563"?
If I test that out, does it matter if the SSL box is checked or not?
(I never understood what the difference was with or with that SSL checked.)
Using <news:1kgyqw4a9o4nj.dlg@b.rose.tmpbox.news.arcor.de>, Bernd Rose
wrote:
Is a login even required for news.neodome.net?
AFAICT, for posting: yes, for reading: no.
A lot of news servers are that way (for example, news.dizum.net:119).
But you need an account and port 563 to post to them most of the time.
Encryption doesn't need a certificate to be valid. This way, you just can't >> be sure, that the target server really /is/ the one you are trying to
connect to. It might be an unfriendly server /impersonating/ the other one.
Does that mean I could have omitted stunnel altogether and just used the 40tude dialog user setup with "Host = news.neodome.net" & "Port = 563"?
If I test that out, does it matter if the SSL box is checked or not?
(I never understood what the difference was with or with that SSL checked.)
Does that mean I could have omitted stunnel altogether and just used the
40tude dialog user setup with "Host = news.neodome.net" & "Port = 563"?
Maybe and no. Dialog.exe was compiled 2005 and uses (at best) encryption methods that have been developed until then. (It is a bit more complicated, because it may profit from /some/ updates to OS encryption functions. But
in the whole, Dialog encryption is stuck in 2005.)
If the NNTP server still supports at least one of these old encryption methods, then connecting directly to the server on port 563 from Dialog
(with SSL ticked /on/) would work. (Neodome seems to.) Quite a few NNTP servers disabled all these old (and insecure) encryption methods, though. With them, direct encrypted connection from Dialog will /not/ work.
Using sTunnel in any case will not only ensure, that encrypted connection
to a server will succeed with contemporary encryption methods. It will also prevent usage of outdated (insecure) methods. Therefore, even /if/ a server still permits encrypted connection directly from Dialog, it is better to
use the workaround via sTunnel.
If I test that out, does it matter if the SSL box is checked or not?
(I never understood what the difference was with or with that SSL checked.)
The SSL box indicates, whether encryption should be used when sending information to the target address (server and port) configured inside
Dialog. If you enter the external NNTP server name and its port, you need
to check with the provider, whether encryption is supported or not. Usually, port 119 means "no encryption" (SSL box off) and port 563 means "encryption" (SSL box on).
If you enter a local (sTunnel) address, you /could/ encrypt this local connection, as well. You'd need to configure sTunnel for local encryption, though, and you'd need to permit the usage of outdated encryption methods
for this, as well. This makes no sense, whatsoever. Therefore, any local connection (your localhost:55555 for example) should be configured without encryption (SSL box off). This has no influence on the encryption state
for the outgoing connection to the NNTP server, which /will/ be encrypted
by sTunnel, as long as you don't explicitly tell it to /not/ do it. (Which, again, wouldn't make any sense...)
A lot of news servers are that way (for example, news.dizum.net:119).
But you need an account and port 563 to post to them most of the time.
using remailers for posting works most of the time ... no account needed
Dialog does allow me to set news.neodome.net:563 with SSL. And that works. Even though the certificate (we think) has expired.
Does SSL NOT check certificates to see if they've expired?
The SSL box indicates, whether encryption should be used when sending
information to the target address (server and port) configured inside
Dialog. If you enter the external NNTP server name and its port, you need
to check with the provider, whether encryption is supported or not. Usually, >> port 119 means "no encryption" (SSL box off) and port 563 means "encryption" >> (SSL box on).
If you enter a local (sTunnel) address, you /could/ encrypt this local
connection, as well. You'd need to configure sTunnel for local encryption, >> though, and you'd need to permit the usage of outdated encryption methods
for this, as well. This makes no sense, whatsoever. Therefore, any local
connection (your localhost:55555 for example) should be configured without >> encryption (SSL box off). This has no influence on the encryption state
for the outgoing connection to the NNTP server, which /will/ be encrypted
by sTunnel, as long as you don't explicitly tell it to /not/ do it. (Which, >> again, wouldn't make any sense...)
I think I see what you're saying SSL does. It's a LOCAL encryption.
So if I checked the Dialog SSL box AND if I used Stunnel, it would be twice encrypted, is that what I'm hearing you say will be happening?
VanguardLH wrote:
Is a login even required for news.neodome.net?
AFAICT, for posting: yes, for reading: no.
I figured sTunnel was superflous since Dialong can use SSL to make connections. The point of sTunnel is to use it with programs that don't support secured connnections, like really old NNTP, email, or other
clients too old to have added SSL, or they are only supporting SSL3
which got deprecated, or encryption algorithms that got dropped.
Using <news:879f4360c37366ed1912e3a3261b1150@dizum.com>, D wrote:
On Sun, 7 Jan 2024 04:22:08 -0700, david <this@is.invalid> wrote:
A lot of news servers are that way (for example, news.dizum.net:119).
But you need an account and port 563 to post to them most of the time.
using remailers for posting works most of the time ... no account needed
I don't get it.
Every time I mention dizum or mixmin someone mentions remailers.
Yet you can READ from both of them using your news reader alone.
No email is ever involved.
It used to be you could POST to both of them also, before the spammers
drove them nuts and their news admins had to turn off posting.
But even then, you could POST to both of them using Dialog & Stunnel.
Email is NEVER involved.
So why do people always bring up "remailers" when I mention mixmin/dizum? >Call me confused.
Bernd Rose <b.rose.tmpbox@arcor.de> wrote:
VanguardLH wrote:
Is a login even required for news.neodome.net?
AFAICT, for posting: yes, for reading: no.
Would think it was the other way around: no login needed for reading,
login perhaps required for posting.
On Sun, 7 Jan 2024 08:40:27 -0500, Ronald wrote:
Does that mean I could have omitted stunnel altogether and just used the
40tude dialog user setup with "Host = news.neodome.net" & "Port = 563"?
If I test that out, does it matter if the SSL box is checked or not?
(I never understood what the difference was with or with that SSL checked.)
I tested posting to Neodome using Dialog without Stunnel.
This failed.
Host: news.neodome.net
Port: 563
SSL: unchecked
Username: abcdefg
Password: xxxxxxx
Allwd. conn.: 2
Use pipelining (unchecked)
This worked.
Host: news.neodome.net
Port: 563
SSL: checked
Username: abcdefg
Password: xxxxxxx
Allwd. conn.: 2
Use pipelining (unchecked)
So Vanguard was correct that Stunnel wasn't needed to post.
But it did not work without checking the Dialog "SSL" checkbox.
What did that Dialog "SSL" checkbox do to make it work?
VanguardLH wrote:
I figured sTunnel was superflous since Dialong can use SSL to make
connections. The point of sTunnel is to use it with programs that don't
support secured connnections, like really old NNTP, email, or other
clients too old to have added SSL, or they are only supporting SSL3
which got deprecated, or encryption algorithms that got dropped.
*All* encryption methods supported by Dialog are depreciated. The most current version supported is TLS_1.0. Even the (unsupported) TLS_1.1
is already depreciated.
Using <news:879f4360c37366ed1912e3a3261b1150@dizum.com>, D wrote:
A lot of news servers are that way (for example, news.dizum.net:119).
But you need an account and port 563 to post to them most of the time.
using remailers for posting works most of the time ... no account needed
I don't get it.
Every time I mention dizum or mixmin someone mentions remailers.
On Sun, 7th Jan 2024 10:09:11 -0600, VanguardLH wrote:
Bernd Rose <b.rose.tmpbox@arcor.de> wrote:
VanguardLH wrote:
Is a login even required for news.neodome.net?
AFAICT, for posting: yes, for reading: no.
Would think it was the other way around: no login needed for reading,
login perhaps required for posting.
That's what I wrote. ;-)
I don't get it.
Every time I mention dizum or mixmin someone mentions remailers.
For mixmin: http://news.mixmin.net/banana/m2n.html
They *do* operate a mail-to-news gateway. As you mention, the news.mixmin.net server is read-only, so only good for lurking, not for participating in Usenet, leaving only their M2N gateway to participate.
I actually have a filter to ignore-flag any posts originating at Neodome
news.neodome.net:
119 - read/write
119 (STARTTLS) - read/write
563 (SSL) - read/write
For the /other/ servers, a login was specified:
test login: test
test password: test
When I added Neodome to Dialog and tested access (read), I needed no
login credentials to read.
I wasn't interested in using Neodome, so I didn't try submitting an article (write).
news.neodome.net:
119 - read/write
119 (STARTTLS) - read/write
563 (SSL) - read/write
Since news.neodome.net does not require a login, and since everything
posted to Usenet is public, don't see why SSL/TLS is even needed to use Neodome, or any other Usenet provider that does not require a login
(e.g., BOFH paganini, AIOE until they died).
You are connecting to news.neodome.net, not to neodome.net. Their cert
is flawed. It is a self-signed cert; that is, they created it instead
of using a CA (Certificate Authority). My guess is they need to
regenerate their self-signed cert to identify CN = news.neodome.net
which is the host to which you are connecting. They probably instead
get a free site cert from LetsEncrypt.
A self-signed cert does not need to be time ranged, so it won't expire. However, notice their cert does have an expiration:
notAfter=Dec 31 21:59:46 2020 GMT
Maybe that gets ignored for self-signed certs.
So, it is an expired self-signed certificate
On Sun, 7 Jan 2024 13:15:09 -0600, VanguardLH wrote:
I don't get it.
Every time I mention dizum or mixmin someone mentions remailers.
For mixmin: http://news.mixmin.net/banana/m2n.html
They *do* operate a mail-to-news gateway. As you mention, the
news.mixmin.net server is read-only, so only good for lurking, not for
participating in Usenet, leaving only their M2N gateway to participate.
I think "david" missed the point of the post from "D <J@M>" which,
I think, was that all these problems with encrypted servers can be
worked around by using anonymous remailer software instead of nntp.
At least I think that based on what he said, and on his headers.
Can you please look at the headers from "D <J@M>" for me please?
Subject: Re: (Dialog) How do I debug a 40tude "socket error" ...
Injection-Info: neodome.net; posting-account="mail2news"; key="###";
mail-complaints-to="abuse@neodome.net"
Comments: This message did not originate from the Sender address above.
It was remailed automatically by anonymizing remailer software.
Please report problems or inappropriate use to the remailer
administrator at <abuse@dizum.com>.
Comments: This message was transferred to Usenet via mail2news gateway at
<mail2news@neodome.net>. Please send questions and concerns to
<admin@neodome.net>. Report inappropriate use to <abuse@neodome.net>.
Injection-Date: Sun, 7 Jan 2024 14:35:01 +0000 (UTC)
From: D <J@M>
Message-ID: <879f4360c37366ed1912e3a3261b1150@dizum.com>
Date: Sun, 7 Jan 2024 15:34:50 +0100 (CET)
Newsgroups: news.software.readers
Sender: Nomen Nescio <nobody@dizum.com>
{blank line}
using remailers for posting works most of the time ... no account needed
Since _both_ dizum & neodome are in that header, I can't tell if
"D <J@M>" mailed his original to dizum or to neodome (maybe dizum?).
Can you tell which is the server that "D <J@M>" remailed this to?
I never used a remailer myself.
I think "D <J@M>" was trying to tell us that all these problems we've
been having with certificates for neodome and also the fact that both
dizum and mixmin recently closed down nntp posting due to spammers
(AFAICT) can be immediately resolved by using anonymous remailers.
I'd like to test out the suggestion from "D <J&M>" to try remailers
as a failsafe whenever the encryption for neodome expires again.
Do you know how to send a test message using an anonymous remailer
from Windows to any of those news servers "D <J@M>" seems to have used?
I don't know what "STARTTLS" means though, so I didn't test it.
I finally figured out what happened most likely!
[Neodome]
client = yes
accept = 127.0.0.1:62563
connect = news.neodome.net:563
verify = 0
;verifyChain = yes
;CAfile = ca-certs.pem
;checkHost = news.neodome.net
;OCSPaia = yes
I went back to the original email from the Neodome admin about the setup,
and lo and behold the ONLY thing the admin told me to use was the "verify = 0" line (which he said was because it was a self-signed certificate).
(What is a Dialog socket error anyway?)
You should be able to connect to Neodome port 119 with STARTTLS with sTunnel as an intermediate.
On Mon, 8 Jan 2024 17:35:18 +0100, Bernd Rose wrote:
You should be able to connect to Neodome port 119 with STARTTLS with sTunnel >> as an intermediate.
I'll try that, where sTunnel supports STARTTLS apparently. https://www.stunnel.org/mailman3/hyperkitty/list/stunnel-users@stunnel.org/thread/ENK5JRYVFGJ4ZO25DHKQ7Y6EE4YA3RPC/
But I can't find any nntp examples for the setup of the stunnel.conf file. https://www.google.com/search?q=stunnel.conf+example+nntp+starttls
But I can't find any nntp examples for the setup of the stunnel.conf file. >> https://www.google.com/search?q=stunnel.conf+example+nntp+starttls
[Neodome]
client = yes
accept = 127.0.0.1:55555
connect = news.neodome.net:119
protocol = nntp
should work. Adding any verification (verifyPeer or verifyChain) will fail, though, because this will (again) trigger the certificate expiration.
Explanation:
If you are able to connect through sTunnel to a server, the connection will always be encrypted. (Although, with the right setting, it is possible to
use "null encryption" [aka a non-encrypting "encryption" method].) Telling sTunnel to connect with protocol NNTP on port 119 leads to a handshake with STARTTLS.
The "verify = X" is an outdated sTunnel option and replaced by a couple
of other options, that are more descriptive (like "verifyChain = yes/no").
Setting "verify = 0" means to request a certificate, but do no checking,
at all. A better way to deal with a self-signed certificate would be, to download it from a secure location and keep it locally as peer-Neodome.pem (or any other name). Then use a sTunnel configuration entry like:
[Neodome]
client = yes
accept = 127.0.0.1:62563
connect = news.neodome.net:563
verifyPeer = yes
CAfile = peer-Neodome.pem
As long as the certificate is unchanged on the server, encrypted connection would be established by sTunnel.
To get the certificate in its current state, you can use the above sTunnel settings without the last 2 lines. Connect once to Neodome and use the sTunnel right mouse menu entry "Save Peer certificate -> peer-Neodome.pem"
to retrieve the certificate into the local sTunnel certificate store. (This is inside the <config> subfolder of the main sTunnel directory or somewhere in the virtual store for sTunel.) Afterwards, add the last 2 lines to
ensure the verification process. Please note, that in your case this will fail, because expired certificates are not acceptable for the verification!
Another notice: Saving a certificate will be grayed out, as long as there
was no recent connection to the server.
[Neodome]
client = yes
accept = 127.0.0.1:65535
connect = news.neodome.net:119
protocol = nntp> I don't understand what comes out of the sTunnel log file though.
Here's the sTunnel log for test message number 1.
LOG5[4]: Service [Neodome] accepted connection from 127.0.0.1:61463
LOG5[4]: s_connect: connected 95.216.243.224:119
LOG5[4]: Service [Neodome] connected remote server from 10.211.1.25:61464
LOG5[4]: Connection closed: 1538 byte(s) sent to TLS, 246 byte(s) sent to socket
Here's the sTunnel log for test message number 2.
LOG5[0]: Service [Neodome] accepted connection from 127.0.0.1:40720
LOG5[0]: s_connect: connected 95.216.243.224:119
LOG5[0]: Service [Neodome] connected remote server from 10.211.1.145:40721
LOG5[0]: Connection closed: 2213 byte(s) sent to TLS, 246 byte(s) sent to socket
First line in the sTunnel log file (accepted):
I never specified "127.0.0.1:61463" or "127.0.0.1:40720".
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 105:21:07 |
| Calls: | 6,700 |
| Files: | 12,232 |
| Messages: | 5,350,316 |