• Re: BINKP over TLS

    From Wilfred van Velzen@2:280/464 to Oli on Sat Dec 14 15:51:17 2019
    * Originally in FIDONEWS
    * Crossposted in BINKD

    Hi Oli,

    On 2019-12-14 08:29:58, you wrote to Rob Swindell:

    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.

    But we should agree in fidonet on the default/preferred port to use! So it doesn't have to be specified in the nodelist if you use the default.
    (24553 is unassigned by IANA)

    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)

    Not everyone's dns "interface" is able to set this I think.

    - Nodelist flag (INBS?)

    You mean IBNS: ? Most flags seem to be a 3 letter combination, so maybe use: IBS: ?

    - should we allow self-signed certificates? (yes)

    With the existence of letsencrypt it's not really necessary. But I think it's up to the individuals. As 'client' you should decide for yourself if you really
    want to connect to a server with a selfsigned certificate.

    - which TLS version are allowed? (>= TLS v1.3)

    I think we should follow common practice on the "wider" internet...

    - should the client use alpn?

    If necessary. ;)

    But I have access to a lot of linux machines, older and newer. But none of the openssl and ncat versions I checked seem to support it...?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Alexey Fayans@2:5030/1997 to Alan Ianson on Tue Dec 17 03:44:36 2019
    Hello Alan!

    On Mon, 16 Dec 2019 at 14:29 -0800, you wrote to me:

    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.

    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.

    I don't think the binkd developers are going to bring STARTTLS to the table but we need to hear from them.

    Exactly.

    Synchronet's implementation is looking good to me. Direct TLS
    and is working in my experience.
    Still it requires modification to configurations, nodelist
    changes and probably DNS changes as well. STARTTLS would
    eliminate all of that.
    It requires a binkps listener to receive and "BinkpTLS=true" in the
    node section of sbbsecho.ini for nodes you want to poll with binkps.

    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.

    In fact this doesn't look like a good place to discuss technical
    stuff, BINKD seems like a better one.
    I have eyes on the area so we can move the discussion there if you
    like.

    Sure, I'll crosspost it there.

    * Originally in FIDONEWS
    * Crossposted in BINKD


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Oli@2:280/464.47 to Alexey Fayans on Tue Dec 17 08:33:22 2019
    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.

    If you already know that the other side supports encryption and you 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 manual
    configuration is not even an option. Globally, (1) a new nodelist flag
    is required to indicate support if binkps and its port;

    Now we need to stop introducing new nodelist flags?

    (2) binkps must be supported on DNS level as well, i.e. _binkps._tcp
    SRV records;

    not need if you have a nodelist flag. nodelist flag not needed if 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 to support binkps, and for binkd it may be an issue since node records were not designed for multiple protocols based on different ports.

    So software has to be updated in both cases, especially the mailer. 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 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.

    Do we have a proposal for binkp STARTTLS that doesn't leak unencrypted meta-data?


    * Origin: kakistocracy (2:280/464.47)
  • From Alexey Fayans@2:5030/1997 to Oli on Tue Dec 17 13:26:53 2019
    Hello Oli!

    On Tue, 17 Dec 2019 at 08:33 +0100, you wrote to me:

    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.
    If you already know that the other side supports encryption and you
    want to enforce it, you don't need STARTTLS.

    STARTTLS is needed to run TLS on the same port, and I already explained why it is essential to run it on the same port.

    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.

    This implementation is a proof of concept, but obviously will not be adopted by
    most sysops. And what is the point in security when no-one uses it?

    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;
    Now we need to stop introducing new nodelist flags?

    I didn't say that.

    (2) binkps must be supported on DNS level as well, i.e.
    _binkps._tcp SRV records;
    not need if you have a nodelist flag. nodelist flag not needed if
    there is a _binkps._tcp record.

    That is not true. Some mailers do not support nodelists and rely on DNS. For example, binkd.

    (3) nodelist parsers must be updated to understand new flag;
    Yeah, you should use a nodelist parser that gets updated occasionally.

    Sure. But if something can be done without requiring updates to software, it should be done this way. Less requirements means better adoption.

    (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.
    So software has to be updated in both cases, especially the mailer.

    Yes, the difference is how big are the updates and how much software will need to be updated.

    You still can use unencrypted or CRYPTed sessions, if your software doesn't has support for any new encryption scheme.

    Of course. And I am sure that most sysops will not move to dedicated TLS port because of the complexity. Why designing something that will not be adopted - that is the big question.

    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.
    Do we have a proposal for binkp STARTTLS that doesn't leak unencrypted meta-data?

    Client can initiate STARTTLS right away. Server can wait for STARTTLS handshake
    a few seconds before starting unencrypted session (this will probably introduce
    a few seconds delay with older mailers). Just an example. Probably developers can think of a better way.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Alan Ianson@1:153/757 to Alexey Fayans on Tue Dec 17 03:11:54 2019
    Hello Alexey,

    It's not about believing.

    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_ for SMTP
    and other mail protocols and there are reasons for that, but that
    doesn't mean it is deprecated for everything else.

    I have only ever used STARTTLS with smtp. If STARTTLS is proposed to be depricated for smtp I propose we depricate it here too.

    Synhcronet is not the only software out there.

    No it isn't. It does have a simple to use binkps implementation that other software could use in a similar way.

    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 don't think STARTTLS is going to fly. I really have no strong feelings for or
    against STARTTLS, I just don't think that is what anyone wants today.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alexey Fayans@2:5030/1997 to Alan Ianson on Tue Dec 17 15:14:17 2019
    Hello Alan!

    On Tue, 17 Dec 2019 at 03:11 -0800, you wrote to me:

    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).

    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.
    I have only ever used STARTTLS with smtp. If STARTTLS is proposed to
    be depricated for smtp I propose we depricate it here too.

    There is absolutely no point in deprecating it. There are pros and cons everywhere. Weak place of STARTTLS is STRIPTLS attack. In FIDONET we have a nodelist to indicate support of TLS by a node, which mitigates this.

    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 don't think STARTTLS is going to fly. I really have no strong
    feelings for or against STARTTLS, I just don't think that is what
    anyone wants today.

    I don't see any reasons why not. Any security method can be implemented in a good or a bad way. If method weakness is taken into account when protocol is designed, there is no problem with it. STARTTLS failed for SMTP because it was not implemented in a secure way.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Tommi Koivula@2:221/360 to Alexey Fayans on Tue Dec 17 17:42:40 2019
    On 17.12.2019 12:26, Alexey Fayans : Oli wrote:

    That is not true. Some mailers do not support nodelists and rely on DNS. For
    example, binkd.

    Please don't tell that to my BinkD, it *IS* using the nodelist, not DNS.

    17:41 [4913] BEGIN, binkd/1.1a-99/Linux -pP 2:5030/1997 /etc/binkd/binkd.cfg - 17:41 [4913] Nodelist /bbs/file/base/nodelist/Z2DAILY.351 parsed, 1023 IP-nodes processed (0 sec)
    17:41 [4913] creating a poll for 2:5030/1997@fidonet (`d' flavour)
    17:41 [4913] clientmgr started
    17:41 [4914] Substituted * to fido.bsrealm.net. for 2:5030/1997@fidonet by nodelist
    + 17:41 [4914] call to 2:5030/1997@fidonet
    17:41 [4914] trying fido.bsrealm.net. [2001:470:28:6ee::1]...
    17:41 [4914] connected
    + 17:41 [4914] outgoing session with fido.bsrealm.net:24554 [2001:470:28:6ee::1]
    - 17:41 [4914] OPT CRAM-MD5-2412bf666c649c7335440feb795988ee
    + 17:41 [4914] Remote requests MD mode
    - 17:41 [4914] SYS Music Station
    - 17:41 [4914] ZYZ Alexey Fayans
    - 17:41 [4914] LOC St.Petersburg, Russia

    :)

    'Tommi

    --- Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
    * Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)
  • From Alexey Fayans@2:5030/1997 to Tommi Koivula on Wed Dec 18 01:12:13 2019
    Hello Tommi!

    On Tue, 17 Dec 2019 at 17:42 +0200, you wrote to me:

    That is not true. Some mailers do not support nodelists and rely on
    DNS. For example, binkd.
    Please don't tell that to my BinkD, it *IS* using the nodelist, not
    DNS.

    Natively it doesn't support nodelist, but there are perl hooks, that's right. Not everyone is using them, though.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Alan Ianson@1:153/757 to Alexey Fayans on Tue Dec 17 15:02:52 2019
    Hello Alexey,

    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).

    I did read your reasons for using STARTTLS, and I agree with what you have said
    about it.

    I don't think STARTTLS is what we want today. My thoughts are really unimportant though, that is just what I see generally.

    What is important is what the binkd development team thinks about TLS, STARTTLS
    or something all together different. That will determine where binkd goes if it goes anywhere at all.

    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.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alexey Fayans@2:5030/1997 to Alan Ianson on Wed Dec 18 13:32:39 2019
    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.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Alan Ianson@1:153/757 to Alexey Fayans on Wed Dec 18 17:12:44 2019
    Hello Alexey,

    I believe Michael Dukelsky (2:5020/1042) is the last active binkd developer.

    He is next on my list, I didn't realize he was the only developer. I don't yet have enough to reach out and ask him myself. I know I want to be secure but I don't know the best way to go about that. He may very well have better ideas than I do anyway and I am happy enough that we are having this discussion.

    I've already expressed my ideas, but here's a summary:

    1. STARTTLS is the best option because:

    I have read and agree with your reasons for wanting to use STARTTLS. 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.

    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 do agree with your reasons for STARTTLS, they are good reasons.

    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).

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Rob Swindell@1:103/705 to Alexey Fayans on Wed Dec 18 20:54:29 2019
    Re: BINKP over TLS
    By: Alexey Fayans to Alan Ianson on Wed Dec 18 2019 01:32 pm

    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.

    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. I took a working binkp implementation and made it binkps with less than 10 lines of added or changed code. Others have run completely unmodified BinkD over TLS already. So far, nobody has implemented STARTTLS, so there's nothing to compare it to, but comparing it to zero means binkps wins again.

    1.4. Not less secure than TLS on a dedicated port because it is possible to announce TLS support via nodelist.

    STARTTLS is well known to be less secure than Implicit TLS: https://www.agwa.name/blog/post/starttls_considered_harmful

    2. For any kind of TLS something must be decided on certificate authority.

    Nope. Self-signed certificates provide privacy via TLS just fine.

    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.

    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.

    digital man

    This Is Spinal Tap quote #41:
    Ian Faith: It say's "Memphis show cancelled due to lack of advertising funds." Norco, CA WX: 48.4øF, 42.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.10-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Oli@2:280/464.47 to Alexey Fayans on Thu Dec 19 07:38:15 2019
    I've already expressed my ideas, but here's a summary:

    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 certificate
    authority.

    Or don't us a CA. There is DANE, TOFU and we still have the encrypted session password for authentication ...


    * Origin: kakistocracy (2:280/464.47)
  • From Alexey Fayans@2:5030/1997 to Alan Ianson on Fri Dec 20 00:25:21 2019
    Hello Alan!

    On Wed, 18 Dec 2019 at 17:12 -0800, you wrote to me:

    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.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Alexey Fayans@2:5030/1997 to Rob Swindell on Fri Dec 20 01:24:52 2019
    Hello Rob!

    On Wed, 18 Dec 2019 at 20:54 -0800, you wrote to me:

    binkps requires no protocol change, therefore will be adopted way
    faster.

    Explain, how can something that requires manual configuration changes be adopted way faster than something that doesn't, if at all?

    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?

    I mean that STARTTLS-enabled mailers will continue to connect with older versions and vice versa, and once both sides support STARTTLS, it will start working without any additional actions or configuration changes.

    1.3. Requires significantly less software modified.
    I actually implemented binkps is less than an 30 minutes.

    I already explained what I mean. Not a protocol implementation on a single node, but whole infrastructure to make it all work on all nodes.

    Or in other words, why my binkp still not using TLS when connecting to your node? Do you get what I mean?

    1.4. Not less secure than TLS on a dedicated port because it is
    possible to announce TLS support via nodelist.
    STARTTLS is well known to be less secure than Implicit TLS: https://www.agwa.name/blog/post/starttls_considered_harmful

    I already said a few times that this and other articles criticize existing implementations flaws. I will say that again. If designed properly, it will be as secure as TLS on a dedicated port, just more flexible. And FIDONET ecosystem
    allows that.

    2. For any kind of TLS something must be decided on certificate
    authority.
    Nope. Self-signed certificates provide privacy via TLS just fine.
    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.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Alexey Fayans@2:5030/1997 to Oli on Fri Dec 20 00:56:28 2019
    Hello Oli!

    On Thu, 19 Dec 2019 at 07:38 +0100, you wrote to me:

    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?

    I think I already answered this question. One option is to wait for STARTTLS command from client for a few seconds on incoming connection before sending metadata. That will introduce a few seconds connection delay with older clients, though. There might be a better solution, I just don't know the binkp protocol good enough.

    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.

    Things like that matter in real-time applications, i.e. ajax web pages that make thousands of small requests to server. Not our case really.

    2. For any kind of TLS something must be decided on certificate
    authority.
    Or don't us a CA. There is DANE, TOFU and we still have the encrypted session password for authentication ...

    Without CA the whole thing is just pointless and subject to simple MitM attack.
    So why even talking about security?

    DANE and TOFU are ways to tell that the system supports TLS, not a way to verify its certificate.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Alan Ianson@1:153/757 to Alexey Fayans on Thu Dec 19 14:41:56 2019
    Hello Alexey,

    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.

    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.

    The proposal to depricate STARTTLS is enough for me to depricate it. I am relying the the experience of others and best practise today.

    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.

    In discussions I have had, I have recieved only possitive feedback on 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.

    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.

    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.

    It would be used here at my node.

    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.

    I am going to ask some nodes who have done this for advice on how they did it and if I can do it will netmail you my findings and we can do some testing if you would like.

    I just need to get a bit of free time.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Rob Swindell@1:103/705 to Alexey Fayans on Thu Dec 19 15:43:37 2019
    Re: BINKP over TLS
    By: Alexey Fayans to Rob Swindell on Fri Dec 20 2019 01:24 am

    2. For any kind of TLS something must be decided on certificate
    authority.
    Nope. Self-signed certificates provide privacy via TLS just fine.
    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.

    True, if you're concerned about active MitM attacks (not just passive-snooping). But if you're concerned about active MitM attacks, then you don't want to use STARTTLS either.

    digital man

    Synchronet "Real Fact" #94:
    Synchronet v3.15b was released in October of 2011 (5 years after v3.14a). Norco, CA WX: 65.0øF, 24.0% humidity, 1 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.10-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Paul Hayton@3:770/100 to Alan Ianson on Fri Dec 20 15:31:45 2019
    On 19 Dec 2019 at 02:41p, Alan Ianson pondered and said...

    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.

    Yep supportive of this also.

    If binkd supported TLS most nodes could use it if they choose to.
    It would be used here at my node.

    I would welcome this too.

    Best, Paul

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Alexey Fayans@2:5030/1997 to Alan Ianson on Fri Dec 20 15:41:00 2019
    Hello Alan!

    On Thu, 19 Dec 2019 at 14:41 -0800, you wrote to me:

    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.

    Well, it's not a strong argument you know.

    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.

    Yeah, I guess similar to something I read here. Just some criticism of existing
    imperfect implementations.

    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.

    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.
    The proposal to depricate STARTTLS is enough for me to depricate it. I
    am relying the the experience of others and best practise today.

    Only existing SMTP implementation is deprecated because it was designed in such
    a way that client cannot know if server supports TLS.

    It's also a good thing to be smart when relying on the experience of others. You need to understand the reasons why others are making these decisions. And if these reasons are applicable to the topic (they are not).

    I don't agree. If it will be implemented this way, I can bet it
    will be adopted by less than 1% of systems.
    In discussions I have had, I have recieved only possitive feedback on
    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.

    Sure, it will still less than 1% of all nodes.

    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.

    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. What I am talking about is that
    it requires some actions from every single node to start using binkps. And these actions are way more than simple binary update. Knowing how most people don't like to change configuration I just predict the failure of the protocol because the majority of sysops will simply ignore it.

    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).

    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.
    I am going to ask some nodes who have done this for advice on how they
    did it and if I can do it will netmail you my findings and we can do
    some testing if you would like.

    Sure.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Alexey Fayans@2:5030/1997 to Rob Swindell on Fri Dec 20 16:12:26 2019
    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 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.
    True, if you're concerned about active MitM attacks (not just passive-snooping).

    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.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Rob Swindell@1:103/705 to Alexey Fayans on Fri Dec 20 09:56:21 2019
    Re: BINKP over TLS
    By: Alexey Fayans to Rob Swindell on Fri Dec 20 2019 04:12 pm

    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 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.
    True, if you're concerned about active MitM attacks (not just passive-snooping).

    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.

    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.

    I look at all the applications of Opportunistic TLS and they're all less secure
    than Implicit TLS.

    digital man

    Synchronet/BBS Terminology Definition #73:
    TCP = Transmission Control Protocol
    Norco, CA WX: 66.7øF, 22.0% humidity, 3 mph WSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.10-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Alexey Fayans@2:5030/1997 to Rob Swindell on Fri Dec 20 21:09:33 2019
    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 times
    already. You gotta stop looking back at old SMTP implementation
    that wasn't designed against active MitM attacks in the first
    place.
    I look at all the applications of Opportunistic TLS and they're all
    less secure than Implicit TLS.

    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.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Rob Swindell@1:103/705 to Alexey Fayans on Fri Dec 20 11:55:46 2019
    Re: BINKP over TLS
    By: Alexey Fayans to Rob Swindell on Fri Dec 20 2019 09:09 pm

    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.

    Opportunistic TLS gives both the client and the server (or a MitM) the ability to "opt-out" of using TLS. With an Implicit TLS session, no such option is availble; the entire TCP session is secure, or it doesn't exist.

    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.

    A less funny joke than Binkd's CRYPT option. Seriously.

    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.
    I look at all the applications of Opportunistic TLS and they're all less secure than Implicit TLS.

    Examples?

    NNTP, FTP, IRC.

    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.

    Security is a moving target. If you're going to implement something, 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 to TCP session security and is being phased-out. It would be silly to implement STARTTLS in a newly-defined TCP applictaion protocol today.

    digital man

    Synchronet/BBS Terminology Definition #35:
    HTTP = Hypertext Transfer Protocol
    Norco, CA WX: 71.9øF, 20.0% humidity, 1 mph W wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.10-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Alan Ianson@1:153/757 to Alexey Fayans on Fri Dec 20 14:31:22 2019
    Hello Alexey,

    Well, it's not a strong argument you know.

    It's not my intention to argue at all.

    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.

    They are everywhere, easy to find. I won't attempt listing them.

    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.

    Is implicit TLS anything less than very secure?

    How is it "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.

    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.

    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.

    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.

    The above sums up my thoughts on the matter. That can work now. I am still not to a point where I would ask the binkd deveolopers for anything. In fact, the binkd developers may have other ideas around what a binkps protocol might look like.

    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).

    When we have a binkps standard to work with we can do all that.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alexey Fayans@2:5030/1997 to Rob Swindell on Sat Dec 21 06:01:38 2019
    Hello Rob!

    On Fri, 20 Dec 2019 at 11:55 -0800, you wrote to me:

    So far you didn't provide a single fact proving that good STARTTLS
    implementation is less secure than TLS on a dedicated port.
    Opportunistic TLS gives both the client and the server (or a MitM) the ability to "opt-out" of using TLS.

    Depends on implementation. Protocol (binkp) may require to drop connection if TLS negotiation fails with a node that supports TLS according to nodelist.

    With an Implicit TLS session, no such option is availble; the entire
    TCP session is secure, or it doesn't exist.

    And how is it more secure than above?

    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.
    A less funny joke than Binkd's CRYPT option. Seriously.

    Sure, but did I ever speak about it?

    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.
    I look at all the applications of Opportunistic TLS and
    they're all
    less secure than Implicit TLS.

    Examples?

    NNTP, FTP, IRC.

    Sure, all very old designs without security in mind. Also, all of these are just services while FIDONET is an ecosystem and has a nodelist where TLS support can be indicated. That makes a perfect platform for a truly secure STARTTLS implementation.

    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.
    Security is a moving target. If you're going to implement something,
    as I have with binkps, you shoot for the state of the art, today's
    best practices, not yesterday's.

    Like I said earlier, there is no universal standard for everything. When you design something, you gotta be smart and understand well what you are doing and
    why.

    STARTTLS is yesterday's solution

    Nope, only a few not very well designed implementations are `yesterdays solution`.


    It would be silly to
    implement STARTTLS in a newly-defined TCP applictaion protocol today.

    Nope, it will be silly to design a protocol that has no future.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Alexey Fayans@2:5030/1997 to Alan Ianson on Sat Dec 21 06:30:47 2019
    Hello Alan!

    On Fri, 20 Dec 2019 at 14:31 -0800, you wrote to me:

    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.
    Is implicit TLS anything less than very secure?
    How is it "as secure as plain text" ?

    It is not secure at all when client cannot verify server's certificate authenticity. Anyone in the middle can issue own self-signed certificate and client will be happy to accept it.

    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 now it's not even a FTS proposal, so we are not talking about now, we are talking about what it can be if done properly.

    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.

    Not many. I don't have numbers, but I'd guess that binkd runs on like 90% of all binkp nodes. The rest 10% is shared between multi-protocol mailers and some
    exotic software like BinkIT (I never even heard of it before you named it).

    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.
    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.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Michael Dukelsky@2:5020/1042 to Alexey Fayans on Sat Dec 21 13:13:46 2019
    Hello Alexey,

    Wednesday December 18 2019, Alexey Fayans wrote to Alan Ianson:

    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.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Moscow, Russia (2:5020/1042)
  • From Alan Ianson@1:153/757 to Alexey Fayans on Sat Dec 21 13:58:38 2019
    Hello Alexey,

    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 don't want to force anything. I simply want to listen on port 24553 for TLS capable sessions.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alexey Fayans@2:5030/1997 to Michael Dukelsky on Sun Dec 22 04:35:43 2019
    Hello Michael!

    On Sat, 21 Dec 2019 at 13:13 +0300, you wrote to me:

    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?


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Alexey Fayans@2:5030/1997 to Alan Ianson on Sun Dec 22 04:37:29 2019
    Hello Alan!

    On Sat, 21 Dec 2019 at 13:58 -0800, you wrote to me:

    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 don't want to force anything. I simply want to listen on port 24553
    for TLS capable sessions.

    That is fine if you are going to only accept connection. But if we speaking about an protocol implementation, all aspects should be considered and though through.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Michael Dukelsky@2:5020/1042 to Alexey Fayans on Sun Dec 22 10:13:36 2019
    Hello Alexey,

    Sunday December 22 2019, Alexey Fayans wrote to Michael Dukelsky:

    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 haven't heard anything from him for rather a long time. Maybe he is just reading, I don't know.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Moscow, Russia (2:5020/1042)
  • From Alexey Fayans@2:5030/1997 to Alan Ianson on Mon Dec 23 21:28:53 2019
    Hello Alan!

    On Fri, 20 Dec 2019 at 15:41 +0300, I wrote to you:

    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.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Paul Hayton@3:770/100 to Alexey Fayans on Tue Dec 24 10:32:52 2019
    On 23 Dec 2019 at 09:28p, Alexey Fayans pondered and said...

    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 could share the steps I would love to repro this and test also :)

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Alan Ianson@1:153/757 to Alexey Fayans on Mon Dec 23 14:07:40 2019
    Hello Alexey,

    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.

    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..

    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

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Alexey Fayans on Mon Dec 23 14:15:22 2019
    Hello Alexey,

    If you'd like to try that in the reverse direction Equinox BBSs
    details are..

    EquinoxBBS is node 1:153/757.2

    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


    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alexey Fayans@2:5030/1997 to Paul Hayton on Tue Dec 24 01:07:16 2019
    Hello Paul!

    On Tue, 24 Dec 2019 at 10:32 +1300, you wrote to me:

    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 could share the steps I would love to repro this and test also
    :)

    I have latest version of SSLH (built from source) running with this config:

    === Start of Windows Clipboard ===
    verbose: 0;
    foreground: true;
    inetd: false;
    numeric: true;
    transparent: false;
    timeout: 2;
    user: "nobody";
    pidfile: "/var/run/sslh.pid";
    chroot: "/opt/sslh";

    syslog_facility: "auth";

    listen:
    (
    { host: "0.0.0.0"; port: "24554"; },
    { host: "::"; port: "24554"; }
    );

    protocols:
    (
    { name: "tls"; host: "127.0.0.1"; port: "24553"; },
    { name: "anyprot"; host: "192.168.1.2"; port: "24554"; }
    );

    on_timeout: "anyprot";
    === End of Windows Clipboard ===

    And haproxy listening on 24553 with the following config:

    === Start of Windows Clipboard ===
    global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private

    ssl-default-bind-ciphers EECDH+AESGCM:EDH+AESGCM
    ssl-default-bind-options no-sslv3

    # Custom
    tune.ssl.default-dh-param 2048

    defaults
    log global
    timeout connect 5000
    timeout client 50000
    timeout server 50000

    listen binkps
    mode tcp
    bind 127.0.0.1:24553 ssl crt /etc/ssl/certs/bsrealm.net.pem
    server binkd 192.168.1.2:24554
    === End of Windows Clipboard ===

    Please note that latest SSLH has a bug in on_timeout (on-timeout) config directive handling (see https://github.com/yrutschle/sslh/issues/253) so maybe it's a good idea to use version supplied by your distro.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Alexey Fayans@2:5030/1997 to Alan Ianson on Tue Dec 24 01:22:56 2019
    Hello Alan!

    On Mon, 23 Dec 2019 at 14:07 -0800, you wrote to me:

    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.

    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.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Alan Ianson@1:153/757 to Alexey Fayans on Mon Dec 23 14:42:16 2019
    Hello Alexey,

    Yep, all went good.

    Good stuff.

    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.. :)

    OK.

    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 have a few nodes now I can test with, including yours so I'll get to work on that. Time is an issue. I just got back from shopping and the little lady tells
    me she wants to go shopping so I'm out for a time.. ;)

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Oli@2:280/464.47 to Alan Ianson on Tue Dec 24 08:37:30 2019
    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.


    * Origin: kakistocracy (2:280/464.47)
  • From Alan Ianson@1:153/757 to Oli on Tue Dec 24 04:26:58 2019
    Hello Oli,

    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 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?

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Oli@2:280/464.47 to Alan Ianson on Tue Dec 24 16:21:50 2019
    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?

    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



    * Origin: kakistocracy (2:280/464.47)
  • From Alan Ianson@1:153/757 to Oli on Tue Dec 24 14:24:20 2019
    Hello Oli,

    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?

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Oli on Tue Dec 24 19:20:12 2019
    Hello Oli,

    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;
    }
    }

    Thanks for that, I have binkd listening over TLS now successfully and I can poll 153/757 from 153/757.2

    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

    I'm still getting the error I mentioned, I'll keep working on that.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Oli@2:280/464.47 to Alan Ianson on Wed Dec 25 07:36:16 2019

    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 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?


    * Origin: kakistocracy (2:280/464.47)
  • From Alan Ianson@1:153/757 to Oli on Wed Dec 25 17:22:28 2019
    Hello Oli,

    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 have exchanged netmail with a node using binkd at the remote side. I'll have to figure that out, and find a workable way.

    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?

    Not yet. It is posible to use a letsencrypt cert with Synchronet. If I can't get passed this I'll give it a shot.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Tommi Koivula@2:221/6 to Alexey Fayans on Sun Dec 29 11:01:04 2019

    On 23.12.2019 21:28, Alexey Fayans - Alan Ianson :

    On Fri, 20 Dec 2019 at 15:41 +0300, I wrote to you:

    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.

    ===
    node 2:5030/1997 -pipe "openssl s_client -quiet -alpn binkp -connect *H:*I" * ===

    10:55 [13564] BEGIN, binkd/1.1a-99/Linux -pP 2:5030/1997 /etc/binkd/binkd.cfg - 10:55 [13564] Nodelist /bbs/file/base/nodelist/Z2DAILY.363 parsed, 1023 IP-nodes processed (0 sec)
    10:55 [13564] creating a poll for 2:5030/1997@fidonet (`d' flavour)
    10:55 [13564] clientmgr started
    10:55 [13565] Substituted * to fido.bsrealm.net. for 2:5030/1997@fidonet by nodelist
    + 10:55 [13565] call to 2:5030/1997@fidonet
    + 10:55 [13565] External command 'openssl s_client -quiet -alpn binkp -connect fido.bsrealm.net.:binkp' started, pid 13566
    10:55 [13565] connected
    + 10:55 [13565] outgoing session with fido.bsrealm.net:binkp [fido.bsrealm.net.]
    depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
    verify return:1
    depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
    verify return:1
    depth=0 CN = bsrealm.net
    verify return:1
    - 10:55 [13565] OPT CRAM-MD5-12d5ce5c4d16a57b570ba9f8d15182ee
    + 10:55 [13565] Remote requests MD mode
    - 10:55 [13565] SYS Music Station
    - 10:55 [13565] ZYZ Alexey Fayans
    - 10:55 [13565] LOC St.Petersburg, Russia
    - 10:55 [13565] NDL 100M,IBN,ICM
    - 10:55 [13565] TIME Sun, 29 Dec 2019 11:55:29 +0300
    - 10:55 [13565] VER binkd/1.0.4/Win32 binkp/1.1
    + 10:55 [13565] addr: 2:5030/1997@fidonet
    + 10:55 [13565] addr: 2:5030/1997.9@fidonet

    :)

    'Tommi

    ---
    * Origin: nntps://news.fidonet.fi (2:221/6.0)
  • From Phillip L Taylor Jr@1:275/201.30 to All on Tue Apr 28 22:42:25 2020
    On Tue 17-Dec-2019 8:33 , Oli@2:275/201.0 said to Alexey Fayans:
    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.
    --- CNet/5
    * Origin: 1:275/201.0 (1:275/201.30)
  • From Alan Ianson@1:153/757 to Phillip L Taylor Jr on Tue Apr 28 22:23:22 2020
    Hello Phillip,

    What is TLS and what is different about it from what we are using
    today with the standard Binkd config?

    TLS is Transport Layer Security. It is the successor to SSL. When you use a secure https:// website you are using TLS. It is used for security and privacy.

    If your a hub why would you force your clients to use it? Some of us
    are using some really old operating systems.

    I don't think anyone is forcing anything. You can connect to my node as always on port 24554 or using TLS on port 24553.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Oli@2:280/464.47 to Phillip L Taylor Jr on Wed Apr 29 10:27:16 2020
    28 Apr 20 22:42, you wrote to All:

    On Tue 17-Dec-2019 8:33 , Oli@2:275/201.0 said to Alexey Fayans:
    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?

    the binkp CRYPT extension requires a session password for the encryption. With TLS it's possible to use encryption without a session password.

    If your a hub why would you force your clients to use it?

    I think there is some context missing. IIRC correctly the discussion was about opportunistic TLS:. the connection starts as plaintext and then is upgraded to a TLS encrypted session. A man-in-the-middle can strip the TLS negotiation. To mitigate the attack the client could insist on TLS and refuse any plaintext connection. See
    https://en.wikipedia.org/wiki/Opportunistic_TLS

    There is no standard and for opportunistic TLS with binkp. We are using direct TLS now. The server listens on another port and expects a TLS session on that port (but still can offer plaintext sessions on the IBN port).

    Some of us are using some really old operating systems.

    It's possible to run a TLS proxy on another machine, like a Raspberry Pi or an OpenWRT based router.

    Using Tor and Tor a hidden services is much easier to setup though.


    * Origin: kakistocracy (2:280/464.47)
  • From mark lewis@1:3634/12 to Oli on Wed Apr 29 09:02:06 2020
    Re: BINKP over TLS
    By: Oli to Phillip L Taylor Jr on Wed Apr 29 2020 10:27:16


    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 ;)


    )\/(ark
    --- SBBSecho 3.11-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
  • From Oli@2:280/464.47 to mark lewis on Wed Apr 29 16:19:14 2020
    29 Apr 20 09:02, you wrote to me:

    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 (non existent) .onion address.

    Blocking incoming connections from Tor exit nodes doesn't prevent a hidden service from working.

    I don't recommend unencrypted binkp connections over Tor exit nodes.


    * Origin: kakistocracy (2:280/464.47)
  • From mark lewis@1:3634/12 to Oli on Wed Apr 29 13:01:51 2020
    Re: BINKP over TLS
    By: Oli to mark lewis on Wed Apr 29 2020 16:19:14


    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
    (non existent) .onion address.

    i never said or indicated that i did run such a service... perhaps your statment was too loose or general? or perhaps i misread it? :shrug:


    Blocking incoming connections from Tor exit nodes doesn't prevent a
    hidden service from working.

    no one said it did ;)

    blocking incoming from such also blocks outgoing to such, though... my perimeter firewall does an exceptional job of performing that task :)


    I don't recommend unencrypted binkp connections over Tor exit nodes.

    why not? binkp connections carry state secrets? somehow i don't think so...


    )\/(ark
    --- SBBSecho 3.11-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)