Hi there Matt. Looking forward anything u doin :) i think u need use - So long © as ur special word for something pretty hard and need a lot of time to make it work ^_^
пт, 14 февр. 2025 г., 12:05 cryptearth <cryptea...@cryptearth.de.invalid>: > Well, a simple credential based auth like a password as the most common > and basic form of a challenge-response would work if the webadmin > wouldn't be a rest endpoint. But as it is and the way a rest api is > meant to be used this credential has to be give at each request. Fun > fact: it doesn'T really matter if this "one has to provide some > credential over and over again" is some password, some other kind of > token or even the rather expensive mutual tls. The point is rather a > rest api endpoint is really meant for such. A different approach could > be to convert it from a rest endpoint to something with a continous > connection like the keep-alive header in http to re-use one already > established connection for multiple requests instead of open a new > request for every resource. > The JWT is a good idea although it lacks some example how to set it up > (at least I wasn't able to figure it out) and maybe it could be > simplified to be just an arbitrary token instead of something that > requires cryptography. The idea should be, at least as the first step, > to put some kind of simple protection in place to close the > vulnerability of "it's an open unprotected admin control endpoint". And > if it's just some token set fixed in the config which has to be provided > along. Yes, someone may see this still as vulnerable - but as I > mentioned: when someone already has local access to your server to > extract that token from the config then you likely have way more serious > issues to deal with than someone abusing the james webadmin endpoint. > > Anyway - I try to come up with some example over the weekend. Have to go > to work now. > > So long. > > Matt > > Am 13.02.25 um 02:10 schrieb Ilya Terskov: > > Hi guys, so if using lets encrypt certificate, anyone can get access? > What > > about certificates with password? Client need to write correct one to get > > access? Also additional user/pass layer i think good thing ofc with > > tls/ssl. Thanks for your hard work. I not developer and all i can help u > > with just testing and get logs :( sorry about that, i know i am > disturbing > > you pretty much Matt and Benoit too. > > > > чт, 13 февр. 2025 г., 07:57 cryptearth <cryptea...@cryptearth.de > .invalid>: > > > >> Hello Benoit, > >> > >> I'm happy to provide something back to the James project. Unfortunately > >> I read your reply too late to start work on it over the past weekend. > >> And currently I work long shifts due to high backlog that has to be > >> cleaned up. I try to tinker some lines together over the upcomming > >> weekend and provide them over on my github. > >> > >> Long story short: Setting up your own PKI and some lines of Java to > >> setup mutual TLS is quite easy. James already comes with the required > >> BouncyCastle libs bcpkix, bcprov and bcutil to do so. > >> I have to stress: As by the standard any client certificate signed by > >> any of the specified root PKI will pass the verification - so using > >> Let's Encrypt is discouraged as ANY LE client cert will be valid. To use > >> mutual TLS properly one pretty much has to setup thier own PKI to be in > >> control of any certificates issued. > >> Also both Java SSE and BouncyCastle are able to perform basic validity > >> checks like CRL or OCSP but these has to be kept up along. As the RFC > >> only recommends these to have setup but not actually require them the > >> simplest setup is a root ca certificate and two leaf certificates, one > >> for the server and one for the client, without all the fancy stuff like > >> AIA, CRL-dp or any of the other x.509 extensions. > >> This can also be done with a few simple openssl commands (and unless > >> you're a java dev with a jdk installed that's likely the better > >> solution) - but as I'm a hobbyist java dev I always did it this way and > >> don't know the openssl commands. So someone with experience in both my > >> provide a "translation". > >> > >> Anyway - I see how I have time and report back if I have some example > >> written down. > >> > >> Have a good one. > >> > >> Greetings, > >> > >> Matt > >> > >> Am 09.02.25 um 22:55 schrieb Benoit TELLIER: > >>> Hi there > >>> I had a private discussion couple of week ago with Jean HELOU who > >> complained of webadmin being hard top secure and hé proposer settings > up an > >> optional basic auth scheme, easier to use that the jwt bearer token. > >>> Would this be helping? > >>> Would this be something you would be willing to contribute, with > >> guidance? > >>> Idem for repairing the TLS setup, or making it usable with pem files... > >>> > >>> -- > >>> > >>> Best regards, > >>> > >>> Benoit TELLIER > >>> > >>> General manager of Linagora VIETNAM. > >>> Product owner for Team-Mail product. > >>> Chairman of the Apache James project. > >>> > >>> Mail: btell...@linagora.com > >>> Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) > >>> > >>> > >>> Le févr. 8, 2025 6:06 PM, de Cryptearth <cryptea...@cryptearth.de > .INVALID>Hi > >> Ilya, > >>> for me in my very own personal opinion using RSA keys would be fine > >>> already, or any other established public-key auth like SSH. But JWT > >>> already is some sorts of this which just has to be implemented > >>> correctly. I tried to look into it but honestly not really understood > >>> it. So I guess if someone could give me just an example I likely would > >>> be able to figure it out on my own. > >>> > >>> Another option I already use on other projects: mutual TLS. > >>> It's easy to setup your own PKI and using client certificates for both > >>> authentication and identification is part of the TLS standard itself > and > >>> works with established servers like apache httpd. Implementing it in > >>> java is as easy as to set your own root-ca-cert as trustanchor when > >>> creating the TLS server socket. The server then requests a client > >>> certificate signed by the root-ca-cert (even works with intermediate > >>> certs) during the handshake and if none is presented the connection is > >>> terminated. All the verification is done by the java SSE itself - > nothin > >>> complicated to implement - just setup two certificates. > >>> > >>> Should this be a (or THE) route to implement security on webadmin? I > >>> don'T think so. It's an open admin control port and no matter if it > >>> comes with some sort of auth or ident it should always be treated as > >>> such - which means: only accessible local and protected by firewall at > >>> the very least. Yes, there still should be some security on top - but > it > >>> often comes down to: if an attacker already got local access to your > >>> server in most cases you lost already. > >>> > >>> So, TLDR: For me if, for some reason, one need remote access to james > >>> webadmin just use ssh tunneling like > >>> > >>> ssh user@host -L8443:localhost:8443 > >>> > >>> and use the local 8443 and let ssh handle the auth and ident and crypto > >>> and all that stuff. We already have this tool at hand - and: "Don't > roll > >>> your own crypto!". > >>> > >>> > >>> Am 07.02.25 um 10:26 schrieb Ilya Terskov: > >>>> yeah guys i tried that in the end but one problem - if i have forwards > >> to > >>>> other email - it need to delete also, same for aliases, so if doing > >> script > >>>> it need to do all that and recursively. > >>>> we sure need 3.9.0 with actions working :) about security on it i > think > >> we > >>>> need just RSA keys just like used in SSH and ofc encryption on this > >>>> chanel no plaintext for sure :) > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org > >> For additional commands, e-mail: server-user-h...@james.apache.org > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org > For additional commands, e-mail: server-user-h...@james.apache.org > >
