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: | 718 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 143:07:16 |
| Calls: | 12,138 |
| Calls today: | 6 |
| Files: | 15,021 |
| Messages: | 6,520,059 |