| Time |
S |
Nick |
Message |
| 00:45 |
|
pdurbin |
bear: I hadn't really thought of an ircd logging the channel as a privacy thing, but I see what you mean. If the channel is logged, the expectation is the topic says "this channel is being logged" and in the nick list you see a bot with a name like "irclogger". |
| 01:03 |
|
prologic |
its actually even worse than that |
| 01:03 |
|
prologic |
an irc server operator can basically intercept all messages anyway |
| 01:03 |
|
prologic |
or modify the ircd to capture all exchanged messages |
| 01:04 |
|
prologic |
I'm thinking about ways to solve for this as well where despite the server being used as the "exchange" that the server cannot "see" the messages at all |
| 01:04 |
|
prologic |
because they are encrypted e2e from each participating client |
| 01:19 |
|
bear |
that could be part of the secure channel flag - clients would need to establish e2e credentials in order to join |
| 01:34 |
|
prologic |
could work |
| 01:34 |
|
prologic |
ofc much of that kind of e2e encryption would require some sane client support |
| 01:34 |
|
prologic |
do we use GPG? |
| 01:34 |
|
prologic |
Signal? |
| 01:34 |
|
prologic |
how do you get client support into Textual, mIRC, X-Chat, HExChat, irssi, Palaver, MutterIRC, etc |
| 01:40 |
|
bear |
yea, e2e channels will almost mean custom client IMO |
| 02:02 |
|
prologic |
Or... |
| 02:02 |
|
prologic |
We could implement supplementary software to go along with eris |
| 02:02 |
|
prologic |
that acts as a proxy |
| 02:02 |
|
prologic |
normal client -> proxy (via localhost)-> server |
| 02:03 |
|
prologic |
bit like what RobustIRC => https://robustirc.net/ |
| 02:03 |
|
prologic |
but for a different purpose (e2e enc) |
| 02:13 |
|
bear |
that would enable bots to act on behalf of a registered secure user |
| 02:18 |
|
prologic |
indeed |
| 02:18 |
|
prologic |
not such a bad idea? |
| 02:18 |
|
prologic |
if you want e2e enc; run up this local proxy? |
| 02:19 |
|
prologic |
make sure you use a trusted irc network that runs a trusted ircd -- Eris *cough* |
| 02:19 |
|
prologic |
Or... |
| 02:19 |
|
prologic |
Hmm no nvm |
| 02:20 |
|
prologic |
I was thinking; what about building Eris to support storing/exchanging public GPG keys |
| 02:20 |
|
prologic |
the proxy would then know what to do with these and encrypt messages appropriately using the right public keys depending on recipient or channel |
| 02:31 |
|
bear |
your talking about eris being a key server no? |
| 02:33 |
|
bear |
the closest thing I can think of is how keybase does secure channels |
| 02:34 |
|
prologic |
pretty much yeah |
| 02:34 |
|
prologic |
that's what I was thinking |
| 02:34 |
|
prologic |
keybase |
| 02:34 |
|
prologic |
why not |
| 02:34 |
|
prologic |
it doesn't sound too far fetched |
| 02:35 |
|
bear |
to be truly secure the server should only be the transport and even it would not be able to see the messages |
| 02:35 |
|
prologic |
to date I know of no ircds or clients that support native e2e enc |
| 02:35 |
|
bear |
IIRC they were talking about something like this for XMPP's MUCs in the next version of it's protocols |
| 02:35 |
|
prologic |
well if you're talking about e2e enc |
| 02:36 |
|
prologic |
if the server only sees public keys used to enc messages |
| 02:36 |
|
prologic |
then the server can never truely see the enc'd messges |
| 02:36 |
|
prologic |
because it never has the private keys |
| 02:36 |
|
prologic |
this is how keybase works essentially AFAIK |
| 02:36 |
|
bear |
right |
| 02:36 |
|
prologic |
at least from my understanding of how GPG (what is it called techincally) works? |
| 02:36 |
|
bear |
then eris is nothing but a message router |
| 02:36 |
|
prologic |
sure |
| 02:37 |
|
prologic |
the question becomes really |
| 02:37 |
|
bear |
which is perfectly fine - my client can be of two minds with eris |
| 02:37 |
|
prologic |
why can't we support this natively |
| 02:37 |
|
prologic |
without requiring clients to support this or proxies to implement this |
| 02:37 |
|
bear |
because then the server would need enough information to perform the handshake or discovery |
| 02:37 |
|
prologic |
can't we build custom (to be spced out) server-side features to exchange pub key pairs? |
| 02:38 |
|
bear |
my thought would be that eris provides a place for clients to advertise their capabilities and for channels to register what capabilities are required for entry |
| 02:38 |
|
bear |
after that it is then nothing but a transport |
| 02:40 |
|
prologic |
sure |
| 02:40 |
|
prologic |
you could do something like: /mode #foo +E <pubkey> |
| 02:40 |
|
prologic |
then anyone that joins and messages the channel is expected to use that key to encrypt messages |
| 02:40 |
|
bear |
but yes, having it spec'd out as to how client A requests entry to channel Y which is owned by client B |
| 02:40 |
|
bear |
right |
| 02:40 |
|
prologic |
only clients/users actually have a valid matching private key to go with |
| 02:41 |
|
bear |
client B's pubkey would be the channel's and anyone wanting access would have to send an invite request |
| 02:42 |
|
bear |
server receives it, unwraps the envelope, re-wraps it for client B with a stamp that it came from client A (which would be different from what client A signed for OOB verification) |
| 02:42 |
|
prologic |
yeah |
| 02:42 |
|
prologic |
makes sense |
| 02:42 |
|
prologic |
basically the way I share passwords between me and my wife over GPG |
| 02:43 |
|
bear |
yep |
| 02:43 |
|
prologic |
I actually have to encrypt the data twice |
| 02:43 |
|
prologic |
once for her pub key and once or mine |
| 02:43 |
|
bear |
right - stock GPG multi-party stuff |
| 02:43 |
|
prologic |
it would become computationally expensive as the channel member list grows |
| 02:43 |
|
prologic |
which is the only downside |
| 02:44 |
|
bear |
I don't see this level of security being used for large channels |
| 02:45 |
|
bear |
I would see these types of channels: public, private, secure |
| 02:45 |
|
prologic |
me neither but still |
| 02:45 |
|
prologic |
yup |
| 02:45 |
|
pdurbin |
I guess I don't see a problem with ircd being able to capture all exchanged messages. Isn't that like saying a newspaper is capturing all the words the reporter is writing? Isn't it ircd's job to publish words out to readers? |
| 02:45 |
|
bear |
public -- no encryption; private -- server provided channel key; secure -- what were describing above |
| 02:45 |
|
prologic |
pdurbin no :) |
| 02:46 |
|
prologic |
what we're talking about here is another level of privacy |
| 02:46 |
|
prologic |
and the ircd just being a great platform for exchange |
| 02:46 |
|
prologic |
i.e: the transport |
| 02:46 |
|
prologic |
it should not care nor see what clients are exchanging |
| 02:46 |
|
pdurbin |
Ok, I guess I'm interested in exchanging ideas. What you call "public". |
| 02:46 |
|
prologic |
public is fine |
| 02:47 |
|
prologic |
private/secret channels too |
| 02:47 |
|
prologic |
already supproted by Eris quite well |
| 02:47 |
|
prologic |
as well as Secure vs. non-Secure client transports |
| 02:47 |
|
prologic |
but I want to take Eris to a level of privacy/security where the server cannot possibly ever see or know what is being exchanged between clients |
| 02:47 |
|
pdurbin |
XMPP has some sort of "off the record" (OTR) mode. |
| 02:47 |
|
prologic |
we call this "e2e secure" |
| 02:48 |
|
prologic |
yup |
| 02:48 |
|
prologic |
that's what we're talking about :) |
| 02:48 |
|
bear |
yea, OTR is what we were discussing above |
| 02:48 |
|
prologic |
bringing some form of OTR to IRC |
| 02:48 |
|
prologic |
whether it's GPG-multi-party stuff |
| 02:48 |
|
prologic |
Signal |
| 02:48 |
|
prologic |
or something ismilar |
| 02:49 |
|
pdurbin |
Most of the time, when people use OTR with me, I think, "Is this really necessary?" |
| 02:49 |
|
prologic |
since we're on the topic |
| 02:49 |
|
prologic |
what I've seen some folkd do in the wold |
| 02:49 |
|
prologic |
is use fish encryption |
| 02:49 |
|
prologic |
and somehow store the key used for enc/dec in teh channel |
| 02:49 |
|
prologic |
not sure how on that part though |
| 02:49 |
|
prologic |
anyone familiar? |
| 02:50 |
|
prologic |
but this is vulnerable since the key is not asymetric and can be used for both dec and enc |
| 02:50 |
|
prologic |
(I think that's the right terminology) |
| 02:50 |
|
bear |
that's something I could see eris doing is to allow semi-private channels by having discovery of the key |
| 02:50 |
|
pdurbin |
codex is the security guy |
| 02:50 |
|
bear |
well, that can be solved by having that key only be used for the knock - after the auth is done the server would generate a session key |
| 02:51 |
|
prologic |
bear like +p meaning something semi-secure in encryptiuon terms? |
| 02:51 |
|
bear |
but yea, we are getting into the nuts and bolts where I am not comfortable being authoritative |
| 02:51 |
|
prologic |
yeah |
| 02:51 |
|
prologic |
me neither tbh |
| 02:51 |
|
prologic |
but I've been learning a lot about this stuff |
| 02:51 |
|
prologic |
big interest of mine lately |
| 02:52 |
|
prologic |
I will very likely at least toy with some ideas |
| 02:52 |
|
bear |
yep |
| 02:52 |
|
bear |
get some sort of prototype implemented and have folks review it |
| 02:52 |
|
prologic |
meanwhile there was a debate earlier on in #ircv3 and #lobby on Mills about +s vs. +p for channels |
| 02:52 |
|
prologic |
+s (secure) +p (private) |
| 02:52 |
|
prologic |
and whether or not Eris should implement either/or or both |
| 02:53 |
|
prologic |
right now it implements +p -- but it acts more like +s |
| 02:53 |
|
bear |
why not both? |
| 02:53 |
|
prologic |
I don't tbh see the point of supporting +p (private) |
| 02:53 |
|
prologic |
its a question of what one should do over the other |
| 02:53 |
|
prologic |
and what the right behaviors are |
| 02:53 |
|
bear |
+p private is, IMO, an invisible channel that you have to be invited into |
| 02:53 |
|
prologic |
some ircds actually implement +p as a mdoe meaning "no knocks allows" |
| 02:53 |
|
bear |
and only registered users would be allowed |
| 02:53 |
|
prologic |
freenode I think |
| 02:54 |
|
prologic |
hmm |
| 02:54 |
|
prologic |
not sure I agree completely |
| 02:54 |
|
bear |
:) |
| 02:54 |
|
prologic |
since users get +r on conenction if authed |
| 02:54 |
|
prologic |
so its naturelaly for a channel to have +R |
| 02:54 |
|
prologic |
(RegisteredOnly) |
| 02:54 |
|
prologic |
so that makes +p useless (sort of) |
| 02:54 |
|
bear |
ah - I was being imprecise |
| 02:54 |
|
prologic |
:) |
| 02:55 |
|
prologic |
but something I want to sort out before a minor release (1.7) |
| 02:55 |
|
bear |
I should have said "users who are securely connected and have registered with the server" |
| 02:55 |
|
prologic |
oh? |
| 02:55 |
|
prologic |
so +s (securet) means no-one can see the channel unless they are on it or a netop |
| 02:56 |
|
bear |
right |
| 02:56 |
|
prologic |
+p (private) means only registered and securely connected users can see the channel? |
| 02:56 |
|
bear |
yes |
| 02:56 |
|
prologic |
ahhh ha! |
| 02:56 |
|
prologic |
I like this idea |
| 02:56 |
|
prologic |
a lot |
| 02:56 |
|
prologic |
its actually in line with Eris's focus |
| 02:56 |
|
prologic |
nice one bear :) |
| 02:56 |
|
bear |
:) |
| 02:56 |
|
prologic |
can you write this up in an issue and one of us can fix this mess? :) |
| 02:56 |
|
bear |
i've had these thoughts in my brain for many years |
| 02:56 |
|
bear |
sure can |
| 02:57 |
|
prologic |
htank you :) |
| 02:57 |
|
prologic |
yeah apparently so have i :) |
| 02:57 |
|
prologic |
great minds ... :P |
| 02:57 |
|
pdurbin |
bear: please drop a link in here when you're done |
| 02:58 |
|
bear |
yep |
| 02:58 |
|
pdurbin |
thanks |
| 02:59 |
|
prologic |
🙃 |
| 03:00 |
|
prologic |
https://grafana.mills.io/dashboard/db/eris?refresh=10s&panelId=3&fullscreen&orgId=1 |
| 03:01 |
|
prologic |
as it is right now there are 3 insecure users on the Mills network |
| 03:01 |
|
prologic |
although to be fair two of them are probably bots (which their networks are actually secure) |
| 03:01 |
|
prologic |
because they're on the same physical SW |
| 03:01 |
|
prologic |
the 3rd is actually pdurbin himself :P |
| 03:01 |
|
bear |
:) |
| 03:03 |
|
prologic |
oh nope I'm wrong haha |
| 03:03 |
|
prologic |
the bots are connected securely |
| 03:03 |
|
bear |
https://github.com/prologic/eris/issues/35 |
| 03:03 |
|
prologic |
its pdurbin kzisme and Hellson |
| 03:03 |
|
prologic |
haha |
| 03:03 |
|
prologic |
3 users that apparently don't care :) |
| 03:03 |
|
bear |
afk for a bit, doing some chares |
| 03:03 |
|
prologic |
bear danke! |
| 03:03 |
|
bear |
your very welcome |
| 03:03 |
|
prologic |
chores* |
| 03:03 |
|
prologic |
:) |
| 03:04 |
|
pdurbin |
I'm not planning on leaking any secrets on your IRC network, prologic :) |
| 03:04 |
|
prologic |
:P |
| 03:04 |
|
prologic |
that's okay :) |
| 03:04 |
|
prologic |
but as bear just pointed out |
| 03:05 |
|
prologic |
you'll be restricted to "public" channels only ;) |
| 03:06 |
|
pdurbin |
you can restrict me to the logged ones, once they're logged :) |
| 03:12 |
|
pdurbin |
‘I was just learning about open source, and then I’m like, “Wow, all of this can just be, like, taken away by, like, a large company?” And then I became an anarchist.’ https://trackchanges.postlight.com/jenn-schiffer-relates-to-developers-5075c696d7e5 |
| 03:25 |
|
prologic |
pdurbin done deal :P |
| 04:59 |
|
|
kzisme joined #sourcefu |
| 04:59 |
|
|
kzisme joined #sourcefu |
| 08:15 |
|
prologic |
bear https://github.com/prologic/eris/pull/36 |
| 12:15 |
|
aditsu |
pdurbin: she, like, says "like", like, way too much |
| 13:55 |
|
pdurbin |
prologic: you're done with the SQL backend already? Wow. |
| 13:56 |
|
pdurbin |
aditsu: on the rare occasion that I transcribe part of a podcast, I take "like" and "um" out. :) |
| 13:59 |
|
aditsu |
so you're saying you didn't transcribe that :p |
| 14:00 |
|
pdurbin |
nope |
| 14:00 |
|
pdurbin |
good episode though |
| 19:18 |
|
codex |
prologic: share passwords -- please please use lastpass (over sharing over gpg) |
| 19:20 |
|
codex |
prologic: assuming (re: encrypt irc) you are talking about something like this: https://github.com/flakes/mirc_fish_10 |
| 19:21 |
|
codex |
The first question I would ask (and always do when someone says "i want/need to encrypt") is -- who are you trying to protect against? |
| 19:21 |
|
codex |
prologic: (btw, follow up to github link above - http://ultrx.net/doc/fish/) |
| 20:54 |
|
prologic |
codex: umm wtf?! Begging me to use a SaaS is not cool — can you please elaborate on intent and context here? |
