Cool. Next steps are probably to define (or get IANA to assign) an
"official" binkps TCP port number. And then maybe a nodelist flag
should be defined so nodes supporting binkps (instead-of or
in-addition-to binkp) can be automatically identified.
There is much more to do for the standardization. An IANA number is the least important.
Do we really need an official port number? Or is it better to rely on other ways as many nodes use a non-standard port number anyway:
- SRV records (_binkps._tcp should be mandatory)
- Nodelist flag (INBS?)
- should we allow self-signed certificates? (yes)
- which TLS version are allowed? (>= TLS v1.3)
- should the client use alpn?
No it doesn't. MitM attack can only fool client into thinkingI believe it does.
that TLS is not supported. But you can require TLS on a client
side and it will just disconnect, no harm done.
That's why STARTTLS has been depricated.
I don't think the binkd developers are going to bring STARTTLS to the table but we need to hear from them.
Synchronet's implementation is looking good to me. Direct TLS
and is working in my experience.
Still it requires modification to configurations, nodelistIt requires a binkps listener to receive and "BinkpTLS=true" in the
changes and probably DNS changes as well. STARTTLS would
eliminate all of that.
node section of sbbsecho.ini for nodes you want to poll with binkps.
In fact this doesn't look like a good place to discuss technicalI have eyes on the area so we can move the discussion there if you
stuff, BINKD seems like a better one.
like.
No it doesn't. MitM attack can only fool client into thinking
that TLS is not supported. But you can require TLS on a client
side and it will just disconnect, no harm done.
I believe it does.
It's not about believing. You can read on wikipedia for example about
MitM and STARTTLS. MitM can fool client into thinking STARTTLS is not supported. Mitigation is requiring encryption on client side. As
simple as that.
I don't think the binkd developers are going to bring STARTTLS to
the table but we need to hear from them.
Exactly.
Synhcronet is not the only software out there. And manual
configuration is not even an option. Globally, (1) a new nodelist flag
is required to indicate support if binkps and its port;
(2) binkps must be supported on DNS level as well, i.e. _binkps._tcp
SRV records;
(3) nodelist parsers must be updated to understand new flag;
(4) additional configuration must be introduced in mailers to support binkps, and for binkd it may be an issue since node records were not designed for multiple protocols based on different ports.
With STARTTLS none of this is a problem. Additional configuration flag
to require TLS connection is easy to implement, nodelist flag is
optional and may be used to tell client to require TLS when connecting
to supporting node, and additional DNS SRV records are not needed as
well.
It's not about believing. You can read on wikipedia for exampleIf you already know that the other side supports encryption and you
about MitM and STARTTLS. MitM can fool client into thinking
STARTTLS is not supported. Mitigation is requiring encryption on
client side. As simple as that.
want to enforce it, you don't need STARTTLS.
I don't think the binkd developers are going to bring STARTTLS
to the table but we need to hear from them.
Exactly.The had plenty of time. binkp is not only used by binkd. Direct TLS
works today with binkd with some helper software.
Synhcronet is not the only software out there. And manualNow we need to stop introducing new nodelist flags?
configuration is not even an option. Globally, (1) a new nodelist
flag is required to indicate support if binkps and its port;
(2) binkps must be supported on DNS level as well, i.e.not need if you have a nodelist flag. nodelist flag not needed if
_binkps._tcp SRV records;
there is a _binkps._tcp record.
(3) nodelist parsers must be updated to understand new flag;Yeah, you should use a nodelist parser that gets updated occasionally.
(4) additional configuration must be introduced in mailers toSo software has to be updated in both cases, especially the mailer.
support binkps, and for binkd it may be an issue since node
records were not designed for multiple protocols based on
different ports.
You still can use unencrypted or CRYPTed sessions, if your software doesn't has support for any new encryption scheme.
With STARTTLS none of this is a problem. Additional configurationDo we have a proposal for binkp STARTTLS that doesn't leak unencrypted meta-data?
flag to require TLS connection is easy to implement, nodelist
flag is optional and may be used to tell client to require TLS
when connecting to supporting node, and additional DNS SRV
records are not needed as well.
It's not about believing.
That's why STARTTLS has been depricated.
It's not deprecated globally. Deprecation is only _proposed_ for SMTP
and other mail protocols and there are reasons for that, but that
doesn't mean it is deprecated for everything else.
Synhcronet is not the only software out there.
With STARTTLS none of this is a problem. Additional configuration flag
to require TLS connection is easy to implement, nodelist flag is
optional and may be used to tell client to require TLS when connecting
to supporting node, and additional DNS SRV records are not needed as
well.
I'm not going anywhere until I believe, in something. I don't mind
having my beliefs proven to be worthless, in fact I appreciate it if
they are in fact worthless.
That's why STARTTLS has been depricated.
It's not deprecated globally. Deprecation is only _proposed_ forI have only ever used STARTTLS with smtp. If STARTTLS is proposed to
SMTP and other mail protocols and there are reasons for that, but
that doesn't mean it is deprecated for everything else.
be depricated for smtp I propose we depricate it here too.
With STARTTLS none of this is a problem. Additional configurationI don't think STARTTLS is going to fly. I really have no strong
flag to require TLS connection is easy to implement, nodelist
flag is optional and may be used to tell client to require TLS
when connecting to supporting node, and additional DNS SRV
records are not needed as well.
feelings for or against STARTTLS, I just don't think that is what
anyone wants today.
That is not true. Some mailers do not support nodelists and rely on DNS. Forexample, binkd.
That is not true. Some mailers do not support nodelists and rely onPlease don't tell that to my BinkD, it *IS* using the nodelist, not
DNS. For example, binkd.
DNS.
I'm not going anywhere until I believe, in something. I don't
mind having my beliefs proven to be worthless, in fact I
appreciate it if they are in fact worthless.
Well, like I suggested earlier, you can read about STARTTLS on
wikipedia, where you will find confirmation of my words and more
examples of weakness mitigation, including DNS based (DANE) and
MTA-STS (lHSTS for SMTP).
If you have ideas around security in binkd I would send them directly
to one of the binkd developers. Alexey Vissarionov is someone active
in Fidonet and is a binkd deveolper I think. That might be a good
place to start.
I believe Michael Dukelsky (2:5020/1042) is the last active binkd developer.
I've already expressed my ideas, but here's a summary:
1. STARTTLS is the best option because:
1.1. It works on the same port and therefore will be adopted way
faster. 1.2. Can work out of the box without additional configuration. 1.3. Requires significantly less software modified.
1.4. Not less secure than TLS on a dedicated port because it is
possible to announce TLS support via nodelist. 2. For any kind of TLS something must be decided on certificate authority. 2.1. We can use internet CAs, but this will require additional binding of fidonet
address to internet domain, probably, via nodelist. Doesn't look
shiny. 2.2. We can have own CA but this makes fidonet more
centralized, we will also have to define a secure way of issuing and delivering certificates.
Hello Alan!
On Tue, 17 Dec 2019 at 15:02 -0800, you wrote to me:
If you have ideas around security in binkd I would send them directly to one of the binkd developers. Alexey Vissarionov is someone active
in Fidonet and is a binkd deveolper I think. That might be a good
place to start.
I believe Michael Dukelsky (2:5020/1042) is the last active binkd developer.
I've already expressed my ideas, but here's a summary:
1. STARTTLS is the best option because:
1.1. It works on the same port and therefore will be adopted way faster.
1.2. Can work out of the box without additional configuration.
1.3. Requires significantly less software modified.
1.4. Not less secure than TLS on a dedicated port because it is possible to announce TLS support via nodelist.
2. For any kind of TLS something must be decided on certificate authority.
2.1. We can use internet CAs, but this will require additional binding of fidonet address to internet domain, probably, via nodelist. Doesn't look shiny. 2.2. We can have own CA but this makes fidonet more centralized, we will also have to define a secure way of issuing and delivering certificates.
I've already expressed my ideas, but here's a summary:
1. STARTTLS is the best option because:
2. For any kind of TLS something must be decided on certificate
authority.
I don't think STARTTLS is what we want today.
In the early going of TLS it was probably the only way forward since
there were many destinations that did not support TLS, that is not the case today. I don't read of anyone adopting STARTTLS today, only depricating it.
If binkps over TLS was implemented today I think implicit TLS is the
way to do it.
We need a binkps listener on port 24553 (or the post you
intend to use) and a way to start a poll to such a listener.
I would be willing to test TLS with you if you like, even using
STARTTLS. If we got some testing under our belt we could discover what works and what doesn't and be in a better position to give feedback to
the binkd developer(s).
binkps requires no protocol change, therefore will be adopted way
faster.
1.2. Can work out of the box without additional configuration.Not sure what "box" you're referring to, but there's currently no
BinkP mailers that support STARTTLS, so how could you possibly know
what configuration will be needed?
1.3. Requires significantly less software modified.I actually implemented binkps is less than an 30 minutes.
1.4. Not less secure than TLS on a dedicated port because it isSTARTTLS is well known to be less secure than Implicit TLS: https://www.agwa.name/blog/post/starttls_considered_harmful
possible to announce TLS support via nodelist.
2. For any kind of TLS something must be decided on certificateNope. Self-signed certificates provide privacy via TLS just fine.
authority.
A CA is only needed if you're going to use TLS for trust. If you're
only using TLS for privacy, then a CA-signed certificate is not
needed.
1. STARTTLS is the best option because:How do you encrypt the metadata that is sent on connection? Can
STARTTLS negotiated before node infos are sent?
Will this add another roundtrip?
Direct TLS will give us a quick path to QUIC, which would reduce connection times instead of making the protocol slower.
2. For any kind of TLS something must be decided on certificateOr don't us a CA. There is DANE, TOFU and we still have the encrypted session password for authentication ...
authority.
I don't think STARTTLS is what we want today.
Why?
In the early going of TLS it was probably the only way forward
since there were many destinations that did not support TLS, that
is not the case today. I don't read of anyone adopting STARTTLS
today, only depricating it.
I only see a proposal to deprecate STARTTLS _implementation_ in SMTP
and other e-mail protocols because obviously implementation has flaws.
If implemented properly, I don't see any reason for deprecation.
If binkps over TLS was implemented today I think implicit TLS is
the way to do it.
I don't agree. If it will be implemented this way, I can bet it will
be adopted by less than 1% of systems.
We need a binkps listener on port 24553 (or the post you
intend to use) and a way to start a poll to such a listener.
And for that we will need a lot of software updated on a lot of
systems. Which will most probably never happen.
I would be willing to test TLS with you if you like, even using
STARTTLS. If we got some testing under our belt we could discover
what works and what doesn't and be in a better position to give
feedback to the binkd developer(s).
I am not a true coder, at least, I don't have enough skill/time to implement any kind of TLS support in binkd. If someone will do it,
I'll be happy to test.
2. For any kind of TLS something must be decided on certificateNope. Self-signed certificates provide privacy via TLS just fine.
authority.
A CA is only needed if you're going to use TLS for trust. If you're only using TLS for privacy, then a CA-signed certificate is not
needed.
The whole sentence is wrong. CA is required to make sure that the certificate provided by server was not replaced by an attacker during MitM attack. With self-signed certificate you can never tell that you are connecting to the real system, unless you know a CA pubkey used to sign that self-signed certificate. That's kinda basic stuff.
If binkd could listen on a secure TLS port (24553) and poll nodes listening on a secure port I'm sure it would be widely accepted although
I wouldn't guess a pecentage.
If binkd supported TLS most nodes could use it if they choose to.
It would be used here at my node.
I don't think STARTTLS is what we want today.
Why?Because of what I have read others say on the subject. I really have
no good idea why it is frowned upon.
The first encounter I had with binkps was about a year ago when
SSL/TLS was introduced in Mystic. Mystic has oppotunistic SSL/TLS
support. It had to be oppotunistic since James knew at the outset
there would be mailers in the mix that did not support SSL/TLS. James received a lot of feedback on the subject that implicit TLS was the
way to go rather that Opportunistic.
Since then I have looked up the subject. There is a mountain of information on the subject and I have not read it all, but I don't see folks adopting STARTTLS today, only depricating it.
I only see a proposal to deprecate STARTTLS _implementation_ inThe proposal to depricate STARTTLS is enough for me to depricate it. I
SMTP and other e-mail protocols because obviously implementation
has flaws. If implemented properly, I don't see any reason for
deprecation.
am relying the the experience of others and best practise today.
I don't agree. If it will be implemented this way, I can bet itIn discussions I have had, I have recieved only possitive feedback on
will be adopted by less than 1% of systems.
the idea of implementing binkps with TLS. I will go ahead and
implement binkps in my own setup when I can, with nodes who wish it
and support it.
I have done this already with Mystic's mailer (Mystic's implementation needs work) and Synchronet's BinkIT mailer. binkps using TLS is a
reality today for those using the BinkIT mailer. I have successfully
sent and recieved netmail using Synchronet's BinkIT mailer with binkd
on the remote side.
BinkIT's mailer uses implicit TLS and is very secure and I would like
to be able to do this with binkd as well, since I use binkd on my node 153/757.
If binkd could listen on a secure TLS port (24553) and poll nodes listening on a secure port I'm sure it would be widely accepted
although I wouldn't guess a pecentage.
For a start there is the BinkIT mailer that supports TLS now.
There are other mailers in use also that likely won't be updated (Argus/Irex) but I think the binkd mailer is the most used today
looking at my own logs. If binkd supported TLS most nodes could use it
if they choose to.
I am not a true coder, at least, I don't have enough skill/timeI am going to ask some nodes who have done this for advice on how they
to implement any kind of TLS support in binkd. If someone will do
it, I'll be happy to test.
did it and if I can do it will netmail you my findings and we can do
some testing if you would like.
The whole sentence is wrong. CA is required to make sure that theTrue, if you're concerned about active MitM attacks (not just passive-snooping).
certificate provided by server was not replaced by an attacker
during MitM attack. With self-signed certificate you can never tell
that you are connecting to the real system, unless you know a CA
pubkey used to sign that self-signed certificate. That's kinda
basic stuff.
But if you're concerned about active MitM attacks,
then you don't want to use STARTTLS either.
Hello Rob!
On Thu, 19 Dec 2019 at 15:43 -0800, you wrote to me:
The whole sentence is wrong. CA is required to make sure that theTrue, if you're concerned about active MitM attacks (not just passive-snooping).
certificate provided by server was not replaced by an attacker
during MitM attack. With self-signed certificate you can never tell
that you are connecting to the real system, unless you know a CA
pubkey used to sign that self-signed certificate. That's kinda
basic stuff.
Isn't it your main argument against STARTTLS?
But if you're concerned about active MitM attacks,
then you don't want to use STARTTLS either.
Why not? It is perfectly mitigated and I explained that a few times already. You gotta stop looking back at old SMTP implementation that wasn't designed against active MitM attacks in the first place.
Isn't it your main argument against STARTTLS?Under no case is Opportunistic TLS (e.g. STARTTLS) as secure as
Implicit TLS.
Yes, the use of self-signed certs is less secure than
CA-signed certs, but that's a different matter and true for both Opportunistic and Implicit TLS.
Why not? It is perfectly mitigated and I explained that a few timesI look at all the applications of Opportunistic TLS and they're all
already. You gotta stop looking back at old SMTP implementation
that wasn't designed against active MitM attacks in the first
place.
less secure than Implicit TLS.
Hello Rob!
On Fri, 20 Dec 2019 at 09:56 -0800, you wrote to me:
Isn't it your main argument against STARTTLS?Under no case is Opportunistic TLS (e.g. STARTTLS) as secure as Implicit TLS.
So far you didn't provide a single fact proving that good STARTTLS implementation is less secure than TLS on a dedicated port.
Yes, the use of self-signed certs is less secure than
CA-signed certs, but that's a different matter and true for both Opportunistic and Implicit TLS.
Use of self-signed certs without a well-defined and implemented mandatory mechanism to verify these certs (either trusted CA or any other similar way) just turns whole security talk into a joke. Seriously.
Why not? It is perfectly mitigated and I explained that a few timesI look at all the applications of Opportunistic TLS and they're all less secure than Implicit TLS.
already. You gotta stop looking back at old SMTP implementation
that wasn't designed against active MitM attacks in the first
place.
Examples?
Maybe you are just looking at bad / not suitable implementations.
Not all implementations are focused on MitM protection and that is fine, similar to use of self-signed certs just to make it a bit harder to sniff the traffic.
Well, it's not a strong argument you know.
Since then I have looked up the subject. There is a mountain of
information on the subject and I have not read it all, but I
don't see folks adopting STARTTLS today, only depricating it.
Any examples of real deprecations? Even if there are, I bet only implementations where client cannot verify if server supports TLS
(like initial SMTP implementation) are being deprecated.
BinkIT's mailer uses implicit TLS and is very secure and I would
like to be able to do this with binkd as well, since I use binkd
on my node 153/757.
Let's start talking about "very secure" when there will be a mechanism
to verify/trust peers' certificates. Right now it's as secure as plain text.
If binkd could listen on a secure TLS port (24553) and poll nodes
listening on a secure port I'm sure it would be widely accepted
although I wouldn't guess a pecentage.
Yeah, the problem is that it won't magically start doing that.
For a start there is the BinkIT mailer that supports TLS now.
Great. How many sysops are using it?
There are other mailers in use also that likely won't be updated
(Argus/Irex) but I think the binkd mailer is the most used today
looking at my own logs. If binkd supported TLS most nodes could
use it if they choose to.
Have you seen binkd configuration? Currently it is not possible to
define a node supporting two protocols specifying ports. And
hardcoding TLS port is not an option obviously.
And if we imagine that node syntax will be changed, binkd nodelist parser(s) will need to be updated as well in order to understand
nodelist flag where binkps port is specified (similar to IBN).
So far you didn't provide a single fact proving that good STARTTLSOpportunistic TLS gives both the client and the server (or a MitM) the ability to "opt-out" of using TLS.
implementation is less secure than TLS on a dedicated port.
With an Implicit TLS session, no such option is availble; the entire
TCP session is secure, or it doesn't exist.
Use of self-signed certs without a well-defined and implementedA less funny joke than Binkd's CRYPT option. Seriously.
mandatory mechanism to verify these certs (either trusted CA or any
other similar way) just turns whole security talk into a joke.
Seriously.
timesWhy not? It is perfectly mitigated and I explained that a few
they're allalready. You gotta stop looking back at old SMTP implementationI look at all the applications of Opportunistic TLS and
that wasn't designed against active MitM attacks in the first
place.
less secure than Implicit TLS.
Examples?
NNTP, FTP, IRC.
Maybe you are just looking at bad / not suitable implementations.Security is a moving target. If you're going to implement something,
Not all implementations are focused on MitM protection and that is
fine, similar to use of self-signed certs just to make it a bit
harder to sniff the traffic.
as I have with binkps, you shoot for the state of the art, today's
best practices, not yesterday's.
STARTTLS is yesterday's solution
It would be silly to
implement STARTTLS in a newly-defined TCP applictaion protocol today.
Let's start talking about "very secure" when there will be aIs implicit TLS anything less than very secure?
mechanism to verify/trust peers' certificates. Right now it's as
secure as plain text.
How is it "as secure as plain text" ?
Yeah, the problem is that it won't magically start doing that.I'm not suggesting magic. For now, nodes who want binkd to listen for
TLS will need to run a second listener.
For a start there is the BinkIT mailer that supports TLS now.
Great. How many sysops are using it?I have one link using the binkit mailer. How many use it is unknown to
me.
Have you seen binkd configuration? Currently it is not possibleUltimately I would like binkd to listen on port 24553 for incoming
to define a node supporting two protocols specifying ports. And
hardcoding TLS port is not an option obviously.
polls over TLS, and I need a way to configure binkd to poll supporting nodes over TLS where it is supported.
That was an easy sentence to write but may not be so easy to
impliment.
I believe Michael Dukelsky (2:5020/1042) is the last active binkd developer.
Ultimately I would like binkd to listen on port 24553 for
incoming polls over TLS, and I need a way to configure binkd to
poll supporting nodes over TLS where it is supported. That was an
easy sentence to write but may not be so easy to impliment.
You cannot force everyone to use a single port. At some places that
just cannot be done, i.e. when several nodes are sharing a single IP address.
I believe Michael Dukelsky (2:5020/1042) is the last active binkdSorry no, I am not a binkd developer. Neither is Alexey Vissarionov.
developer.
From time to time I make some changes in RNtrack and Husky, but not in binkd.
Ultimately I would like binkd to listen on port 24553 for
incoming polls over TLS, and I need a way to configure binkd to
poll supporting nodes over TLS where it is supported. That was
an easy sentence to write but may not be so easy to impliment.
You cannot force everyone to use a single port. At some placesI don't want to force anything. I simply want to listen on port 24553
that just cannot be done, i.e. when several nodes are sharing a
single IP address.
for TLS capable sessions.
I believe Michael Dukelsky (2:5020/1042) is the last active
binkd developer.
Sorry no, I am not a binkd developer. Neither is Alexey
Vissarionov. From time to time I make some changes in RNtrack and
Husky, but not in binkd.
Ouch. Do you know if Pavel Gulchouck (2:463/68) is still active?
I know that it is not hard from technical side. I can even run both
TLS and clear text protocols on the same port via SSLH.
Actually I did it just for fun as a PoC. My system is reachable both via binkp and binkps on a single port - 24554. It also uses a LetsEncrypt certificate. You can try it.
Actually I did it just for fun as a PoC. My system is reachable both
via binkp and binkps on a single port - 24554. It also uses a
LetsEncrypt certificate. You can try it.
If you'd like to try that in the reverse direction Equinox BBSs
details are..
equinoxbbs.ddns.net
Binkp is port 24554 and binkps is 24555.
I Don't know how to get binkd to listen or poll over binkps/TLS. If I
can figure that out I will test on my node.
Ttyl :-),
Al
Actually I did it just for fun as a PoC. My system is reachableIf you could share the steps I would love to repro this and test also
both via binkp and binkps on a single port - 24554. It also uses
a LetsEncrypt certificate. You can try it.
:)
I did poll your node successfully over binkps, I think.
I also sent you a netmail from 1:153/757.2 and I think it was sent to
your node by binkps.
If you'd like to try that in the reverse direction Equinox BBSs
details are..
I Don't know how to get binkd to listen or poll over binkps/TLS. If I
can figure that out I will test on my node.
Yep, all went good.
If you'd like to try that in the reverse direction Equinox BBSs
details are..
I will wait for some kind of standard, when I can force binkd to use
TLS based on nodelist flags automatically.. :)
I Don't know how to get binkd to listen or poll over binkps/TLS.
If I can figure that out I will test on my node.
I just posted my config, so you can try it if you like. But that's
about listenig. I didn't try polling anyone, but I think someone here posted an example.
I Don't know how to get binkd to listen or
poll over binkps/TLS. If I can figure that
out I will test on my node.
I Don't know how to get binkd to listen or
poll over binkps/TLS. If I can figure that
out I will test on my node.
I posted several messages with different options how to do it (in
fidonet and fsxnet). If you have some specific questions, I'm happy to help.
I posted several messages with different options how to do it (in
fidonet and fsxnet). If you have some specific questions, I'm
happy to help.
I saw some posts by you and others but I got lost in the ports,
stunnels and proxy's.
Can you give me an example to..
A. Have binkd listen on port 24553 for binkps/TLS?
B. Poll a binkps node listening for binkps/TLS polls?
B. Poll a binkps node listening for binkps/TLS polls?
binkd.cfg:
node 1:153/757.2 -pipe "openssl s_client -quiet -alpn binkp -connect *H:*I" equinoxbbs.ddns.net:24555
Can you give me an example to..
A. Have binkd listen on port 24553 for binkps/TLS?
e.g. with nginx (change the path to a valid cert / key pair)
nginx.conf:
stream {
server {
listen 24553 ssl;
ssl_certificate
/etc/haproxy/ssl/ssl-cert-snakeoil.pem;
ssl_certificate_key /etc/haproxy/ssl/ssl-cert-key-snakeoil.pem;
proxy_pass 127.0.0.1:24554;
}
}
B. Poll a binkps node listening for binkps/TLS polls?
binkd.cfg:
node 1:153/757.2 -pipe "openssl s_client -quiet -alpn binkp -connect *H:*I" equinoxbbs.ddns.net:24555
When I poll 153/757.2 like this from 153/757
I get a TLS error. At the remote side
(153/757.2) I see this..
BINKPS connection accepted from:
2600:3c04::f03c:92ff:fe69:8db0 port 47496
BINKPS JavaScript service thread started
BINKPS TLS ERROR 'Recieved TLS alert
message: Handshake failure' (-15) setting
session active
I'm currently using a self signed cert on
153/757.2, could that be the problem?
BINKPS connection accepted from:
2600:3c04::f03c:92ff:fe69:8db0 port 47496
BINKPS JavaScript service thread started
BINKPS TLS ERROR 'Recieved TLS alert
message: Handshake failure' (-15) setting
session active
i think it is a problem with the TLS library binkit is using.
I'm currently using a self signed cert on
153/757.2, could that be the problem?
self-signed should be fine, but their might be other problems with the cert. have you tried another one?
On Fri, 20 Dec 2019 at 15:41 +0300, I wrote to you:
AF> I know that it is not hard from technical side. I can even run both
AF> TLS and clear text protocols on the same port via SSLH.
Actually I did it just for fun as a PoC. My system is reachable both
via binkp and binkps on a single port - 24554. It also uses a
LetsEncrypt certificate. You can try it.
No it doesn't. MitM attack can only fool client into thinking
that TLS is not supported. But you can require TLS on a client
side and it will just disconnect, no harm done.
I believe it does.
What is TLS and what is different about it from what we are using
today with the standard Binkd config?
If your a hub why would you force your clients to use it? Some of us
are using some really old operating systems.
On Tue 17-Dec-2019 8:33 , Oli@2:275/201.0 said to Alexey Fayans:
thinkingNo it doesn't. MitM attack can only fool client into
clientthat TLS is not supported. But you can require TLS on a
side and it will just disconnect, no harm done.
I believe it does.
What is TLS and what is different about it from what we are using
today with the standard Binkd config?
If your a hub why would you force your clients to use it?
Some of us are using some really old operating systems.
Using Tor and Tor a hidden services is much easier to setup though.
Using Tor and Tor a hidden services is much easier to setup
though.
it also isn't allowed everywhere either... try connecting to my site/system via Tor using any protocol you desire ;)
(non existent) .onion address.Using Tor and Tor a hidden services is much easier to setup
though.
it also isn't allowed everywhere either... try connecting to my
site/system via Tor using any protocol you desire ;)
If you don't offer a Tor hidden service, I cannot connect to your node's
Blocking incoming connections from Tor exit nodes doesn't prevent ahidden service from working.
I don't recommend unencrypted binkp connections over Tor exit nodes.
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,041 |
| Nodes: | 15 (0 / 15) |
| Uptime: | 150:31:12 |
| Calls: | 500,914 |
| Calls today: | 1 |
| Files: | 109,372 |
| D/L today: |
3,343 files (740M bytes) |
| Messages: | 304,959 |
| Posted today: | 3 |