• 2 Posts
  • 26 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle

  • The issue here is that these are solvable problems, release compat isn’t a new problem. It’s just a problem that takes dedicated effort to solve for, just like any other feature.

    This is something FOSS apps tend to lack simply due to the nature of how contributions tend to work for free software. Which is an unfortunate reality, but a reality none the less.


  • People really underestimate the value of stability and predictability.

    There are some amazing FOSS projects out there ran by folks who don’t give a crap about stability or the art of user experience. It holds them back, and unfortunately helps drive a fragmented ecosystem where we get 2,3,5 major projects all trying to do the same thing.


  • Because the majority of my traffic and services are internal with internal DNS? And I want valid HTTPS certs for them, without exposing my IP in the DNS for those A records.

    If I don’t care about leaking my IP in my a records then this is pretty easy. However I don’t want to do this for various reasons. One of those being that I engage in security related activities and have no desire to put myself at risk by leaking.

    Even services that I exposed to the internet I still don’t want to have my local network traffic go to the internet and back when there is no need for that. SSL termination at my own internal proxy solves that problem.

    I now have this working by using the cloudflare DNS ACME challenge. Those services which I exposed to the internet cloudflare is providing https termination for, cloudflare is then communicating with my proxy which also provides https termination. My internal communication with those services is terminated at my proxy.



  • I stated in the OP that cloudflair HTTPS is off :/

    I’m not using cloudflare for the certificate. I also can’t use the cloud for certificate anyways for internal services through a loopback.

    Similarly you can have SSL termination at multiple layers. That’s works I have services that proxy through multiple SSL terminations. The issue that I’m having is that the ACME challenge seems to be having issues, these issues are documented and explained in various GitHub threads, however the set of solutions are seemingly different and convoluted for different environments.

    This is why I’m asking this question here after having done a reasonable amount of research and trial and error.


  • I am doing SSL termination at the handoff which is the caddy proxy. My internal servers have their SSL terminated at caddy, my traffic does not go to the internet… It loops back from my router to my internal Network.

    However DNS still needs to have subdomains in order to get those certificates, this cloudflair DNS. I do not want my IP to be associated with the subdomains, thus exposing it, therefore cloudflair proxy.

    You’re seeing the errors because the proxy backend is being told to speak HTTPS with Caddy, and it doesn’t work like that.

    You can have SSL termination at multiple points. Cloudflare can do SSL termination and Cloudflair can also connect to your proxy which also has SSL termination. This is allowed, this works, I have services that do this already. You can have SSL termination at every hop if you want, with different certificates.

    That said, I have cloudflair SSL off, as stated in the OP. Cloudflare is not providing a cert, nor is it trying to communicate with my proxy via HTTPS.

    Contrary to your statement about this not working that way, cloudflair has no issues proxying to my proxy where I already have valid certs. Or even self signed ones, or even no certs. The only thing that doesn’t work is the ACME challenge…


    Edit: I have now solved this by using Cloudflair DNS ACME challenge. Cloudflair SSL turned back on. Everything works as expected now, I can have external clients terminate SSL at cloudflair, cloudflair communicate with my proxy through HTTPS, and have internal clients terminate SSL at caddy.









  • I’m not sure why you’re so dismissive of this? It’s kind of asinine.

    Does everyone everywhere only ever use computers in an enclosed room? Is everyone with something value to exfiltrate easily accessible to kidnap and beat with a wrench?

    This is valuable for corporate espionage, political purposes, or for nation states. If miniaturized, even easier for targeted attacks where it might be difficult to inject malware, or for broad attacks on office workers.

    And the best part is that it doesn’t leave a trace which beating someone with a wrench and malware would do…



  • I’m not claiming some grand level of knowledge here. I also cannot enumerate all risks. The difference is that I know that I don’t know, and the danger that poses towards cognitive biases when it comes to false confidence, and a lack of effective risk management. I’m a professional an adjacent field, mid way into pivoting into cybersecurity, I used to think the same way, that’s why I’m so passionate here. It’s painful to see arguments and thought processes counter to the fundamentals of security & safety that I’ve been learning the past few years. So, yeah, I’m gonna call it out and try and inform.

    All that crap said:

    And you are right, the problem gets moved. However, that’s the point, that’s how standardization works, and how it’s supposed to work. It’s a force multiplier, it smooths out the implementation. Moving the problem to the OS level means that EVERYONE benefits from advanced in Windows/Macos/Linux. Automatically.

    It’s not signal’s responsibility, it shouldn’t be unless that’s a problem they specifically aim to solve. They have the tools available to them already, electron has a standardized API for this, secureStorage. Which handles the OS interop for them.

    I’m not arguing that signal needs to roll their own here. The expectation is that they, at least, utilize the OS provided features made available to their software.


  • Another risk with Monitor, which may get better with time. Is that FOSS rust projects have a tendency to slow down or even stall due to the time cost of writing features, and the very small dev community available to pick up slack when original creators/maintainers drop off, burn out, or get too busy with life.

    To be clear: I have nothing against rust. It’s a fantastic language filling in a crucial gap that’s existed for decades. However, it’s I’ll suited for app development, that’s just not it’s strength.



  • Having Signal fill in gaps for what the OS should be protecting is just going to stretch Signal more than it already does. I would agree that if Signal can properly support that kind of protection on EVERY OS that its built for, go for it. But this should be an OS level protection that can be offered to Signal as an app, not the other way around.

    Damn reading literacy has gone downhill these days.

    Please reread my post.

    But this should be an OS level protection that can be offered to Signal as an app, not the other way around.

    1. OSs provide keyring features already
    2. The framework signal uses (electron) has a built in API for this EXACT NEED

    Cmon, you can do better than this, this is just embarrassing.


  • That’s all hinges on the assumption that your computer is pwned. Which is wrong

    You don’t necessarily have to have privileged access to read files or exfiltrated information.

    That point doesn’t matter anyways though because you’re completely ignoring the risk here. Please Google “Swiss cheese model”. Your comment is a classic example of non-security thinking… It’s the same comment made 100x in this thread with different words

    Unless you can list out all possible risks and exploits which may affect this issue, then you are not capable of making judgement calls on the risk itself.