I'm just posting this to start a conversation and gauge interest,
support and ideas in this subject :)
I wonder if BBS developers that are active here would be open to
exploring new protocols (or re-tasking contemporary ones) so that new agreed standards to further develop software for secure, robust interconnected BBS can be agreed upon and implemented between
contemporary systems?
I'm not sure exactly what you want, and I don't understand how we could make public messages more secure by encrypting them during travel, because they're public at the end points. Private messages could be encrypted between systems, but the sysop would still be able to read the messages. For fully private messages, I can see PGP being used, perhaps even embedded into client terminals - but that wouldn't need to change the transport.
On 19-Dec-2018 14:36, deon wrote to Avon <=-
My last post will show that I'm thinking of this topic.
One thing I'm struggling through is:
* Keeping legacy tools active (many of us are here re-living our 20's through that software)
* Leveraging today's protocols.
I think we can compliment "the network" with today's protocols, so that the legacy systems can continue as they were originally designed. I'd
like to see that...
One thing I'm struggling through is:
* Keeping legacy tools active (many of us are here re-living our 20's through that software)
* Leveraging today's protocols.
I think we can compliment "the network" with today's protocols, so that the legacy systems can continue as they were originally designed. I'd
like to see that...
I don't know. I'm happy to implement new things, but I am not an expert
on security and I know nothing about mesh networking.
I'm not sure exactly what you want, and I don't understand how we could make public messages more secure by encrypting them during travel,
because they're public at the end points. Private messages could be encrypted between systems, but the sysop would still be able to read the messages. For fully private messages, I can see PGP being used, perhaps even embedded into client terminals - but that wouldn't need to change
the transport.
not.). This is only as strong as the weakest link though: If any system allows non-secure, it's all for not. It sounds like g00r00 has some Bink (TLS?) thing he's been working on - this could work with legacy systems, but again only if *all* the systems in the network used it; And did not expose via other non-secure methods.
Yes, balancing those two will be tough. It may be that those using
legacy systems have to refrain from doing certain things, but we can use the modern stuff to help with that.
I agree, balancing these will be a challenge. The one thing I will say isOn 19-Dec-2018 14:36, deon wrote to Avon <=-
One thing I'm struggling through is:
* Keeping legacy tools active (many of us are here re-living our 20's through that software)
* Leveraging today's protocols.
Yes, balancing those two will be tough. It may be that those using
legacy systems have to refrain from doing certain things, but we can use the modern stuff to help with that.
On 12-19-18 09:07, deon wrote to vk3jed <=-
On 12/19/18, vk3jed said the following...
Yes, balancing those two will be tough. It may be that those using
legacy systems have to refrain from doing certain things, but we can use the modern stuff to help with that.
I dont think so - but when I can pilot something, I'll put it out there
to try and see if it works.
On 12-19-18 09:32, Sargon wrote to vk3jed <=-
* One really incredible thing that was done in the 80s and 90s was building a network without a central infrastructure or authority. Sure
we used the public phone system, but what was overlaid atop was much
more functional. What could be done today in that spirit? Could we use some of the long-range wireless technologies to build a network
(perhaps in a mesh) that operates via a community vs. on the commercial Internet?
Here's some of my thoughts on the topic:
* Securing communications is key. Related to that is the concept of authenticity. Having the ability to have some level of certainty that
a message is authentic (i.e. not modified, spoofed, suppressed) even is such a message is public (e.g. EchoMail), knowing that it's been
handled by trusted nodes, etc. is a good concept for us to thing about.
Again, some of this is already in place but there are improvements we could consider.
* What can be done to extend communications to areas where the
Internet is still not widely available or affordable. One advantage of the BBS systems is that they were relatively efficient on the wire out
of necessity. Could they be used to bring affordable comms to others.
For example, could we use similar technology to FidoNet/FsxNet on a
mobile device that has a pay-per-bit data plan in underdeveloped areas?
I'm not against web interfaces per say but I think if someone wanted to run communications in a secure fashion and a node involved in the network sent/recieved messages securely.. but still offered them all up via a crawlable HTML interface... again it's all for naught :(
Agreed on Wi-Fi, the distance is too short. I was suggesting technologiesOn 12-19-18 09:32, Sargon wrote to vk3jed <=-
* One really incredible thing that was done in the 80s and 90s was building a network without a central infrastructure or authority. Su we used the public phone system, but what was overlaid atop was much more functional. What could be done today in that spirit? Could we u some of the long-range wireless technologies to build a network (perhaps in a mesh) that operates via a community vs. on the commerci Internet?
Well, I see us doing the same overlaid on the Internet. Wifi is not practical except in high population density areas. From my perspective
as possibly the only BBS sysop/user in a city of 100,000 people with the nearest BBS person being in Melbourne, 150km away.
This is where I get annoyed at web interfaces that expose data to search bots that index it and allow folks to display it via google searches etc.
I guess in this increasingly 'digital footprint' aware world. I think
I think moving forward the trick is:
1) Create a new way of doing things.
2) DO NOT WORRY ABOUT BACKWARDS STANDARDS
3) The old way still works. The new way with security does not need to replace the 50 year old fidonet standards. That way no one gets shouted at by the elf lords.
I guess in this increasingly 'digital footprint' aware world. I th
I think moving forward the trick is:
1) Create a new way of doing things.
2) DO NOT WORRY ABOUT BACKWARDS STANDARDS
3) The old way still works. The new way with security does not need
to replace the 50 year old fidonet standards. That way no one gets
shouted at by the elf lords.
If they only knew Apam had a BBS that could use SQL instead of dos
based message bases from 30 years ago, they would lose their minds.
as an option! (Sorry Nu, but if the elf lords are coming with torches and pitch forks, better you than me :P)
not.). This is only as strong as the weakest link though: If any system allows non-secure, it's all for not. It sounds like g00r00 has some Bink (TLS?) thing he's been working on - this could work with legacy systems,
I think moving forward the trick is:
1) Create a new way of doing things.
On 12/19/18, Tiny said the following...
I think moving forward the trick is:
1) Create a new way of doing things.
I came across this...
https://www.youtube.com/watch?v=IPSbNdBmWKE
On 12-19-18 18:04, Sargon wrote to Vk3jed <=-
Agreed on Wi-Fi, the distance is too short. I was suggesting
technologies such as LoRaWAN, NB-IoT, LTE-M which have ranges in the
10s of KMs. Not to say an overlay over the Internet shouldn't be done
as well. Personallly I don't see the two as mutually exclusive.
On 12-20-18 11:33, Avon wrote to Tiny <=-
On 12/19/18, Tiny pondered and said...
I think moving forward the trick is:
1) Create a new way of doing things.
2) DO NOT WORRY ABOUT BACKWARDS STANDARDS
3) The old way still works. The new way with security does not need to replace the 50 year old fidonet standards. That way no one gets shouted at by the elf lords.
Can't say I disagree :)
It will be interesting to see what can be thought up, created,
developed etc. by interested developers in partnership with the BBS community of users, sysops etc. who have interest and passion to
progress this space in to new areas.
On 12-20-18 08:51, apam wrote to Tiny <=-
Oh and Nu, enigma has sqlite message bases too, and he doesn't have JAM
as an option! (Sorry Nu, but if the elf lords are coming with torches
and pitch forks, better you than me :P)
I signed up to that a few days ago, but have no friends on it. There's a few platforms like that GNU social, and some others.
On 12/20/18, apam said the following...
I signed up to that a few days ago, but have no friends on it. Th
few platforms like that GNU social, and some others.
I just signed up @deon@linuxrocks.online
Looks like they have docker deployment, I could spin up an instance
pretty quickly...
Oh and Nu, enigma has sqlite message bases too, and he doesn't have JAM as an option! (Sorry Nu, but if the elf lords are coming with torches and pitch forks, better you than me :P)
BINKD does have an encryption option but its not secure so not reason to consider it, in my opinion.
(my current first hop requirement is around 150km), but I have some
ideas for getting local tech nerds connected. :)
I signed up to that a few days ago, but have no friends on it. There's a few platforms like that GNU social, and some others.
On Wednesday, December 19th apam muttered...
I signed up to that a few days ago, but have no friends on it. Th
few platforms like that GNU social, and some others.
Which one did you go with? I'm on Mastadon, but it's mostly a
ghosttown & I'm on a fairly active instance haha
I'm not against web interfaces per say but I think if someone wanted run communications in a secure fashion and a node involved in the net sent/recieved messages securely.. but still offered them all up via a crawlable HTML interface... again it's all for naught :(
Once you send a message out, of any kind, you lose a lot of control over what the person/people on the other end might do with it. The contents can be exposed in many ways.
I had someone complain about this re: the Synchronet web interface years ago. I guess they thought they were in the 'underground' and putting
stuff on the web was lame. If the BBS hosting the web interface had blocked guest access to those message areas, crawlers would not have
been able to see them. This was a case of the weakest link dictating
the level of exposure for these messages.
I can see privacy in that sense being a thing for netmail, but it'd be a losing battle for messages to 'public' areas. Distributing these
messages to all kinds of different people who might do anything with
them is sort of baked into the concept of these message networks.
Securing the links and ensuring authenticity of what gets posted is one thing, but even if this stuff isn't on the web you don't have lots of control over how any BBS on the network grants access to it.
This is where I get annoyed at web interfaces that expose data to sea bots that index it and allow folks to display it via google searches
I think it's *generally* fine for fully public bases. But I can see why there may be an annoyance. (BTW: If you want me to disable any of the
FSX* exported stuff Xibalba does via Gopher or NNTP, let me know, it's
no problem!)
There are levels of security here. Even with something like PGP, I could turn around and publicly post a message I decrypted. There is some trust involved. A system that at least doesn't transfer messages over plain text, and a network that has a ruleset of disallowing at least certain areas/etc. in non-secure ways is a start. Outside of that realm it gets
a bit harder to do things without specialized clients.
I agree to a point. When I talk (perhaps naively) about 'secure' I'm talking about content being un-tampered with from creation to recipient receipt, content being encoded so that only the intended recipient can get
Securing the links and ensuring authenticity of what gets posted is
Once that final plain content is received if it's then exposed by the recipient to a wider audience etc. well..after that all bets are off and
one thing, but even if this stuff isn't on the web you don't have
lots of control over how any BBS on the network grants access to it.
That's true in the current context of how BBS operate. But what if that changed? I'm not sure how that new shape of BBS might look but I'm just proffering that nothing is set in stone :)
On 20-Dec-2018 13:25, deon wrote to Vk3jed <=-
On 12/20/18, Vk3jed said the following...
(my current first hop requirement is around 150km), but I have some
ideas for getting local tech nerds connected. :)
How? I'm a tech nerd... :)
My view is work on new technical standards, but in ways that will allow those using legacy systems to make a single point connection to the nextgen network. I'd like to see gateways between the legacy and new technologies as transparent as possible to the end users, regardless of what side of the fence they're on. And we also need to ensure that mail between legacy systems with the nextgen links between is not impacted.
So for example, one can netmail me at 21:1/109, regardless of where they are on the network, or what generation of technology they're running, or even what's in between along the path.
How? I'm a tech nerd... :)
You're not local (in a RF sense :P ).
mastodon.cloud
On 21-Dec-2018 04:00, Avon wrote to Vk3jed <=-
Thanks Tony, good comments .. cheers ears..
On 20-Dec-2018 15:02, deon wrote to vk3jed <=-
On 12/20/18, vk3jed said the following...
How? I'm a tech nerd... :)
You're not local (in a RF sense :P ).
Bugger...
Not counting HF, but the achievable bit rates there are so low we're definitely looking at store and forward and offline solutions, with as
few overheads as possible! :)
How low is low? I'm always up for a challenge.
Oh, and what is HF?
What sort of bitrate can you get on those technologies? I've done a little reading on LoRaWAN, and it's intriguing, but according toLoRaWAN is in the range of a few tens of kilobytes per second (actually close to old school BBS speeds). 10-50 kbits/s is achievable over a pretty far distance, but not the 100KM span you're needing. What's compelling about LoRaWAN is that it operates on the unlicensed spectrum and thus doesn't
Shannon's Law, there is still a tradeoff between effective range and bitrate, thanks to the presence of noise. I'm not familiar with the
other technologies, though the name "LTE-N" suggests this one is related in some way to mobile phone 4G LTE. Here, even 10s of km is way short
(my current first hop requirement is around 150km), but I have some
ideas for getting local tech nerds connected. :)
And yes, no reason why a combination of Internet and RF technologies can't be used. Hams have been doing that for decades now. The first caseI'm aware of that utilised the Intenret is packet radio "wormholes" that date back to at least the very early 90s.
If they only knew Apam had a BBS that could use SQL instead of dos
based message bases from 30 years ago, they would lose their minds.
Agree.
Is there anything special about your Bink/TLS system or is it simply the existing Bink protocol over TLS? Hell, one could set up a TLS proxy if it's the latter.
BINKD does have an encryption option but its not secure so not reason consider it, in my opinion.
Agree.
Is there anything special about your Bink/TLS system or is it simply the existing Bink protocol over TLS? Hell, one could set up a TLS proxy if it's the latter.
On 20-Dec-2018 21:28, deon wrote to vk3jed <=-
On 12/20/18, vk3jed said the following...
Not counting HF, but the achievable bit rates there are so low we're definitely looking at store and forward and offline solutions, with as
few overheads as possible! :)
How low is low? I'm always up for a challenge.
Oh, and what is HF?
On 21-Dec-2018 00:39, Sargon wrote to Vk3jed <=-
LoRaWAN is in the range of a few tens of kilobytes per second (actually close to old school BBS speeds). 10-50 kbits/s is achievable over a
pretty far distance, but not the 100KM span you're needing. What's
compelling about LoRaWAN is that it operates on the unlicensed spectrum and thus doesn't require a mobile operator to function. There's a fair
amount of interesting community projects with the technology. See http://thethingsnetwork.org/ for one.
LTE-M is an IoT technology based on 4G/LTE. It has a slightly higher bitrate around 100 kbits/s. It's lower cost than cellular though it
does require a subscription from a mobile operator.
Yeah, that's along the lines I've been thinking. You can have a "workhole" vis the Internet that that uses something like LoRaWAN to connect a number of participants locally.
Anyway, just some thoughts out loud...
--- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
* Origin: Centarus (21:4/107)
Is it something like STARTTLS or pure TLS. In the latter, stunneling
binkp could work too...
Are there suitable serial devices that can be made to look like modems
for LoRaWAN? Or ones that are basically a network connection? I'm certainly interested in playing with this technology. Combined with
BBSs, it has potential! :)
I mean, yeah SQL is arguably slower, as factually more of a resource hog, and introduces more dependency. What are the benefits though?
The only real requirement is during handshake each side has to wait for the address frame during the welcome stage just to insure that they've both received the NUL options frame (so they can properly decide if the other side supports TLS). Then the client side sends a TLS frame and waits for the ACK from the server before start negotiation. The server sees the TLS frame, sends ACK and immediately starts negotiating the connection.
Its opportunistic TLS (so STARTTLS... but the actual frame name is TLS
to go along with the 3-character frame identifiers that BINKP uses).
The reason I chose that method is because its fully backwards compatible with the existing server.
Its opportunistic TLS (so STARTTLS... but the actual frame name is TLS to go along with the 3-character frame identifiers that BINKP uses).
On Thursday, December 20th g00r00 muttered...
The only real requirement is during handshake each side has to wait for the address frame during the welcome stage just to insure that they've both received the NUL options frame (so they can properly decide if the other side supports TLS). Then the client side sends a TLS frame and waits for the ACK from the server before start negotiation. The server sees the TLS frame, sends ACK and immediately starts negotiating the connection.
I guess I'm more interested in simply putting a TLS proxy in the middle so no code needs written. I'd rather not play in the Bink source code myself. TLS is a transport, so it doesn't really care what's traveling on it. Seems like that's what you described, so a simple proxy should work fine.
Quoting apam to Tiny <=-
Oh and Nu, enigma has sqlite message bases too, and he doesn't have
JAM as an option! (Sorry Nu, but if the elf lords are coming with
torches and pitch forks, better you than me :P)
Quoting g00r00 to Tiny <=-
I mean, yeah SQL is arguably slower, as factually more of a resource
hog, and introduces more dependency. What are the benefits though?
On 22-Dec-2018 05:45, Sargon wrote to vk3jed <=-
I believe there is some, but need to research further. I have a
gateway and device kit on my desk here that just came in, though I've
not had a chance to work with it yet. I do know that the board I have supports AT commands so there's some hope that this will be somewhat
close to a modem.
Will keep you posted...
Not exactly. What g00r00 described is generally known as "explicit TLS", where one of the peers (the client in this case) requests to transition to a TLS-protected stream (also called "opportunistic TLS", e.g. how SMTP STARTTLS works).
A TLS-proxy would require a TCP port dedicated to a TLS-only mode and this is what is called "implicit TLS" (e.g. how HTTPS works).
On Friday, December 21st Digital Man was heard saying...
Not exactly. What g00r00 described is generally known as "explicit TLS", where one of the peers (the client in this case) requests to transition to a TLS-protected stream (also called "opportunistic TLS", e.g. how SMTP STARTTLS works).
A TLS-proxy would require a TCP port dedicated to a TLS-only mode and this is what is called "implicit TLS" (e.g. how HTTPS works).
Heh, thanks for the explinations. I've implemented TLS proxies and MITM more than once from scratch so I'm quite aware of the flavors.
It could still be done with HAPROXY or similar, but it's a shame that it's custom really.
On 22-Dec-2018 10:19, Tiny wrote to apam <=-
Sqlite hasn't been through the FTSC. Totally not something that
could
handle something as important as fightonet.
I'm not sure at least those first two statements are true at all.
"SQL" is simply a language. If we're talking SQLite (I think we are),
I'd wager "it" is certainly much faster than any JAM et. al. based
message format. Multiple index
types, and data structures that have been mulled over by many people
for many many iterations beat the hell out of the old formats. Not a
whole lot of resources, either. These systems work in very tiny
embedded scenarios.
Dependency I *guess* could be a claim, but
linking in a single C file is hardly that (of course it can be a pain
Now if someone wanted to use MySQL, Postgres, etc. in a BBS... sure.
Though again, I *hihgly* doubt you'd even approach the speed.
I mean, yeah SQL is arguably slower, as factually more of a resource and introduces more dependency. What are the benefits though?
I'm not sure at least those first two statements are true at all. "SQL"
is simply a language. If we're talking SQLite (I think we are), I'd
wager "it" is certainly much faster than any JAM et. al. based message format. Multiple index types, and data structures that have been mulled
I guess I'm more interested in simply putting a TLS proxy in the middle
so no code needs written. I'd rather not play in the Bink source code myself. TLS is a transport, so it doesn't really care what's traveling
on it. Seems like that's what you described, so a simple proxy should
work fine.
I mean, yeah SQL is arguably slower, as factually more of a resource hog, and introduces more dependency. What are the benefits though?
No clue man. None at all. My point is why not move foward away from
dos shit? Maybe when someone does something new and exciting we will
find benefits? Maybe not. I'm just saying why not try?
Yup. Implicit TLS is considered more secure, but requires a separate/unique TCP port number, which was originally frowned upon by
the IETF dudes but has since been embraced as how TLS protocols "should" be done.
Yup. Implicit TLS is considered more secure, but requires a separate/unique TCP port number, which was originally frowned upon by the IETF dudes but has since been embraced as how TLS protocols "should" be done.
Well I don't know, I guess it depends on how you are using SQLite. For example I would bet Enigma's Sqlite message bases are faster than magicka's just because I think you know your way around sqlite better than me.
If its faster its only because it uses a massive outrageous amount of memory to keep things in memory. At the end of the day you're comparing a system that parses syntax then performs work based on that syntax and returns formatted results. The work it performs boils down to the same work you'd do directly without SQL...
Its absolutely not faster than directly reading the data unless those things are entirely in memory, in which case you can also do the same with a direct approach.
The only benefit of SQL would be that it is designed for parameter based queries and in that case it excels, but for reading a writing a blob of data from a file its going to be faster to do it directly assuming you index properly.
This was a long time ago though, and no doubt a lot of that has been resolved or worked around by now.
In this specific case... You also lose the ability to use so many 3rd party applications... there are tons of statistic and maintenance utilities as well as tossers that work with JAM.
Not saying its horrible to use SQLite, I'm just saying that shitting on the existing format isn't really founded.
If you're talking about an encrypted transport only yes, but authenticity needs to be considered by the application and of course the client and server need a way to handshake.
You could proxy it but you wouldn't be doing opportunistic TLS you'd have to just have it sitting on an SSL port right?
Yep sqlite, but I also plan to make mysql a possiblity, I think it could be useful if people want to design their own php-mysql type interfaces on top of it.
Not saying its horrible to use SQLite, I'm just saying that shitting on the existing format isn't really founded.
If others started to implement an implicit TLS for BINKP I would as well, I just started here since no one really has to change any configurations to adopt it.
I wouldn't say "considered more secure" about TLS as much as I'd say "STARTTLS is simply not secure at all". This has been well researched
and known for quite some time now. An attacker simply strips the flag
out and viola: No TLS.
No, that's now how SQLite works. Yes, it *does* utilize a *cache* -- if enabled -- and only of data you've already processed. This cache is tiny.
Authenticity of client (client cert validation) and of the server
(server cert validation) are both built into TLS. Public keys could
simply become part of the FTN applicaiton process.
Not saying its horrible to use SQLite, I'm just saying that shitting the existing format isn't really founded.
Agreed with your sentiment here. Though I have to wonder, doesn't something as mature as modern SQLite come with all kinds of monitoring tooling and a wealth of knowledge floating around to make it something easier to maintain?
If others started to implement an implicit TLS for BINKP I would as wel just started here since no one really has to change any configurations adopt it.
For Synchronet's BinkIt to support incoming implicit TLS connections, it would just be a configuration setting in services.ini:
This is simply not true (or wasn't years ago at least). The reason it works fast is because it keeps things in memory just like anything that is transactio based. When you deprive SQLite of memory it turns into a heaping pile (or at least older versions when I last did this sort of experimentation did).
In the BBS world none of this really matters anyway, because we don't see the type of bandwidth to make any of this a big deal, which is sort of what my point is. There isn't a lot of benefit here. If you're starting new like your project, sure then maybe it makes sense.
But you aren't gaining a lot by using a SQLlite database for your message bases over JAM and its certainly arguable that you lose a lot by not doing, because you don't have access to the third party utilities or mail processors. I do agree SQLite has a better design than JAM but thats not really the point.
This is entirely inaccurate. That only works when those same servers are configured to work identically in cleartext, which if you actually use anything with real data to protect... they don't.
Even the various free e-mail providers won't.
On 23-Dec-2018 08:08, apam wrote to NuSkooler <=-
I'm not sure at least those first two statements are true at all.
"SQL" is simply a language. If we're talking SQLite (I think we are),
Yep sqlite, but I also plan to make mysql a possiblity, I think it
could be useful if people want to design their own php-mysql type interfaces on top of it.
Mysql would just be linking to the connector i think, and of course you have to install mysql - so yeah thats a bit more of a dependency, but
the idea is you don't HAVE to, and I expect most people wont use that
as a message base, but those who want to (for whatever reason) can.
Quoting g00r00 to Tiny <=-
I guess I am just saying don't be so quick to hate on the old stuff, because the benefits of switching and rewriting everything for us old folks aren't really that great.
You keep trying to prove a point, but slip in "at least years ago".
I'd love to see your Google searches. I don't doubt there are other
people clueless about this either.
I don't mean to argue with you about any of this, but misinformation is also not good. Yes, STARTLS is very susceptible to downgrade attacks and MITM for the very reason I stated. Including email.
This is why (any sane) mail servers have moved to pure TLS. Of course,
I think its great that you call me clueless. A simple Google search verifies everything I said though. You can even read the actual SQLite sight where they specifically talk about how SQLite performance is heavily determined by memory usage and that in some cases it can be as fast as direct I/O...
So even their own website echos what I am saying, but feel free to call me clueless while I talk about hands on experience in major corporations as part of my job and you reiterate that I'm clueless while providing
This is silly. A few messages ago you clearly didn't seem to even understand my description of opportunistic SSL and now you're acting like an expert?
There is no difference if the server is configured to not operating without SSL. The both listen on a port, one just negotiates the SSL connection immediately, the other one sends a line of text before negotiating SSL. The outcome is identical assuming the server is configured to only allow SSL.
But who cares, you can be right if you want to be! You only have CISSPs and Security Architects in here telling you otherwise, what do they know!
Oh please, do link the page you're referring to on sqlite.org.
No, a few messages ago you lightly stated you "added TLS support", so I questioned how you did it.
I'd say I'm pretty god damn expert level at TLS, yeah. Since I've personally implemented the fucking MITM described more than once profesionally.
For Synchronet's BinkIt to support incoming implicit TLS connections, it would just be a configuration setting in services.ini:
[BINKP]
Port=xxx ; Pick a unique port number here
Command=binkit.js
Options=TLS
I have a link with a Mystic BBS that supports TLS connections although
not implicit at this point. If I put the above in my services.ini in addition to the existing [BINKP] section will that work?
Is it possible with binkit to initiate a TLS session with a Mystic
mailer that supports it (when that is ready)?
This seems like a pretty odd claim, but then its literally impossible for you not to know that what I'm saying is true. If you truly created something "professional" designed to strip STARTTLS commands (why would you?) multiple times (!!) then you know that it was completely useless if the server only accepts TLS.
Either Rob has to implement opportunistic or I need to add implicit. My libraries/servers already do both so I can (and probably will) add the option for implicit too now that I know Synchronet allows it.
Re: Secure Comms
By: Digital Man to g00r00 on Sat Dec 22 2018 03:20 pm
For Synchronet's BinkIt to support incoming implicit TLS connections, it would just be a configuration setting in services.ini:
[BINKP]
Port=xxx ; Pick a unique port number here
Command=binkit.js
Options=TLS
I have a link with a Mystic BBS that supports TLS connections although not implicit at this point. If I put the above in my services.ini in addition to the existing [BINKP] section will that work?
Is it possible with binkit to initiate a TLS session with a Mystic mailer that supports it (when that is ready)?
Google uses STARTLS for mail by default, yes. This of course doesn't matter when using their web client which is pure TLS. When using your
own clients, they recommend to disable fallback due to the very reasons I've started: It's essentially pointless. If the conection can fallback, that's the *only* thing that is needed to perform a downgrade attack and inspect plain text.
I have *not* started that Mystic is inherently insecure. What I started above is what I stated in my last reply and is true: Unless you *force* TLS (and the client sides know to do so as well), it is not secure. It's
You just repeated exactly what I've been saying in every single message to you, that you've been arguing against up until now.
Google's e-mail services simply do not work without STARTTLS; Google uses TLS only. Its secure. Its also an opportunistic handshake like Mystic. There is nothing for them to recommend on the client side because the server is what decides when a connection is accepted. If you try to use a non-SSL connection it is refused regardless of what the client wants, same as Mystic or any other opportunistic server if you force SSL. All are secure and none are at risk for a man in the middle attack.
But thats not what you did. You replied to a message about Mystic's TLS and said that opportunist TLS was insecure.
Any of this ring a bell? Because you've completely flipped now and you're just repeating what I've said to you over and over again.
to you, that you've been arguing against up until now.
No, I'm repeating what I've said over and over. Feel free to go back and read them. That's the neat thing about text. It stays.
"Gmail uses TLS by default, but when a secure connection isn't available (both sender and recipient need to use TLS to create a secure
connection), Gmail will deliver messages over non-secure connections."
And what you said isn't how this actually works. I was taking the higher ground, but since you want to be a jerk, I'll explain it again: What the
Server upgrades to TLS:
SVR to MITM (who it *thinks* is the real client): STARTTLS
MITM: OK
MITM to client: Start plain text.
Client: OK
Google's e-mail services simply do not work without STARTTLS;
Google's e-mail services simply do not work without STARTTLS;
I don't intend to stir the pot or get in the middle of this, but smtp.gmail.com and other gmail mail servers do indeed appear to support implicit TLS on TCP port 465. No "STARTTLS" needed.
Yes that was a sloppy choice of words on my part but the conversation before it wasn't about implicit it was whether it allows cleartext or
not.
What I was trying to show was that it doesn't allow clients to fall back to cleartext at all. They use implicit and opportunistic only for SMTP. SSL required.
Its all good I ended up just adding him to my twit filter.
I have and its exactly like I said it was... Me telling you over and over that its considered secure unless you literally tell it not to use SSL only. Go look.
The MITM can't impersonate an entire SSL connection because the encryption between the legit client and legit server encrypt with a private key that only each side has. Since the MITM doesn't have that, it cannot EVER impersonate the encrypted client connection; The MITM can only intercept and understand or impersonate data *PRIOR* to the SSL handshake and not afterwards.
The Strip attack only strips the cleartext STARTTLS command and HOPES that the server will operate in cleartext entirely when it does. If that doesn't work, then it cannot impersonate the client with an SSL connection without having the private key that only the client has. It does not do what you're said above because it can't without the private key.
I know I'm on g00r00's "twit" list now, but I'll reply anyway since I
think there are others that can benefit from this discussion being
that it is around security and we've been discussing such matters
greatly around here.
On 12/19/18, Tiny said the following...
I think moving forward the trick is:
1) Create a new way of doing things.
I came across this...
https://www.youtube.com/watch?v=IPSbNdBmWKE
I signed up to that a few days ago, but have no friends on it. There's a
few platforms like that GNU social, and some others.
Andrew
--- MagickaBBS v0.12alpha (Linux/x86_64)
* Origin: The Fat Sandwich - sandwich.hopto.org:2023 (21:1/125)
James Digriz wrote to apam <=-
I'm administering a Nextcloud instance and a couple of Owncloud
instances (scheduled to upgrade to Nextcloud soon, when I move their
hosts to CentOS 7. Yes, I know it can be done with 6, if not
officially, but there's more work involved keeping it updated, etc.)
Both offer federated cloud ID's and Nextcloud has the Social app, which interoperate with Mastodon and other social
networks that support the ActivityPub protocol. Gnu social is supposed
to be getting there, iirc. Pretty sure most of the decentralized social media platforms will eventually get there, too. eg. Matrix.org
(riot.im), etc.
James Digriz wrote to apam <=-
I'm administering a Nextcloud instance and a couple of Owncloud instances (scheduled to upgrade to Nextcloud soon, when I move their hosts to CentOS 7. Yes, I know it can be done with 6, if not officially, but there's more work involved keeping it updated, etc.) Both offer federated cloud ID's and Nextcloud has the Social app,which
interoperate with Mastodon and other socialsupposed
networks that support the ActivityPub protocol. Gnu social is
to be getting there, iirc. Pretty sure most of the decentralizedsocial
media platforms will eventually get there, too. eg. Matrix.org (riot.im), etc.
I've played a bit with Mastadon, but without anyone else to talk to on it testing it out is hard. Maybe we should set up a BBS sysops/users presence on M?
... Have you ever questioned the nature of your reality?
--- MultiMail/XT v0.51
* Origin: http://realitycheckbbs.org (21:4/122)
Personally, I'd rather see a robust BBS community using BBS'es :-) But
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 83:53:44 |
| Calls: | 6,658 |
| Calls today: | 4 |
| Files: | 12,203 |
| Messages: | 5,333,599 |
| Posted today: | 1 |