browsermator

you'll still need to trust someone to keep the keys safe. Standard CA cert, or self-signed, PGP or another protocol.... none of those solve your main requirement which is basically "trust no one". All of your security starts there and when you answer the main question which is "who do you trust?"

TOTP usually has all sorts of security problems... often sent through e-mail (insecure), opens up phishing attacks, if server hacked attacker could generate their own, etc... etc... but some 2nd factor is usually better than none.

yes, well that's the cyberbunker... I guess their plan was to self-destruct all servers before the guv got in, but they messed up and left it unattended. This still fails your first requirement of not trusting your identity to anyone.

I just watched a doc on the "cyberbunker" which you might want to check out. The problem became that people trusted the employees of the bunker to not leave the bunker un-attended. Even if they hadn't done that if a guv'ment wanted in, they'd have blasted it open. (or laid siege) So a lot of what you are getting at would be the physical security of the ISP/web host.

"The users must not have to trust anyone with their identity." That'll be a problem. Can you elaborate more on what you mean by that? Also, why does TOTP have better security than Username/Password? (I would argue the opposite in most cases, but it's usually just a 2nd factor, so...) Why is Username/Password considered "poor security"?

I think you're thinking that setting up a server would mean you have a global, internet accessible, IP address. If you setup an intranet, you'll be using either the machine name or a local IP address for the URL.

secure the LAN. You can serve http without exposing that traffic to the internet at all. No one from McDonalds should be able to access your local network.... if that happens now, you've got some serious holes to plug up. You have a lot of options for local network file transfers. Http is probably not what you want but you can do that if you like.

OK, I think you're saying you need access from outside of the LAN. (from the internet not from inside the LAN) That's different than "transfer files between a computer and a cell phone in the same network". Same network is now irrelevant. You'll need user accounts and https or a secure FTP server. (or use some 3rd party service like Google drive)

hmm... define "public". It really sounds like you've got LAN (local network) mixed up with something else, but not real sure.

"I am worried about public hotspots." You can't access your LAN via public hotspot. If your requirement is to provide internet access to your computers on a LAN, that's a whole different ball of wax.

there's no need for HTTP here. Just secure the LAN and that's it. There are various ways to share files over the LAN without HTTP. If you want to create an HTTP "intranet" just be sure there is no way to connect outside of the network. If you have domain-level authentication in place, also be aware of CSRF. (if you're really paranoid and think a machine-name could be leaked/guessed, or if a local client uses localhost for some odd reason) HTTPS on intranet is to mitigate against insider threats. A user in the LAN spying on another user in the LAN.

sry, that was Steffen Ullrich... I'm questioning this line in his answer "even if every mail server involved uses TLS only the connection between the servers is encrypted but not the mail itself. This means that on every server involved in the delivery the mail is available as clear text."

I guess this means it's protected during each hop, but not necessarily from each node it's hopped to... It's going to allow any cert because it can't know via e-mail address which server is actually the destination. (I think I get it a little bit... bottom-line is even secure SMTP is not secure from MITM as is, and you'd have to use additional measures if you use SMTP and need the contents to be secure.)

@schroeder, in the thread you linked to you seem to say that secure e-mail never encrypts the e-mail content/message at all? Even if it doesn't fall-back to plain-text, non-secure protocol?? Did I read that right? I always thought the whole point of secure SMTP was to encrypt the e-mail.

basically the non-secure fallback is still there for most... Outlook:"For receiving mail into Exchange: If the sending server does not support TLS, or if the TLS negotiation fails, Exchange Online will still accept messages unencrypted and without TLS (provided the sending server’s configuration allows that). For sending mail from Exchange: For outbound email, if the receiving server does not support TLS (does not advertise the STARTTLS Verb), Exchange on-premises and Exchange Online will send email without TLS (provided TLS is not forced on the send connector or outbound connector)."

You can force TLS for certain recipients... see here: learn.microsoft.com/en-us/purview/… Unless you know otherwise, e-mail should be considered insecure by default because the fallback to non-secure protocol could be in place.

One of the nastier things a malicious site could possibly do is cause your node server to crash and replace it with their own. Again this is just spit-balling... I have been using Selenium for many years and have never been attacked, but I don't crawl to just any web site, but quite a few I have no control over. I've never been attacked (that I know of...) I don't feel like I have enough expertise with node or jsdom to offer a good answer here, though.

To be fair to Google, that article is from 2013... you'll be most concerned with taking in untrusted content, protecting your locahost, and protecting your code from injections. Using a fresh VM for each run is also a good idea.

Bottom line is it's probably impossible to fully secure a web crawler. Even google had problems such as this: infoworld.com/article/2609489/…

The sandbox in place will take care of javascript execution... (though calls to localhost may still get through and be able to execute something at node.js server) It's what you pull out of the sandbox that is the bigger danger. (or what you send in, if anything confidential is sent) That can easily break out of any code used to process it and/or control your node server.

Even with a "sandbox" in place, you will have code somewhere that is bridging that... (otherwise you couldn't inject into or read the DOM) That is the real danger here... You should have code running outside of the sandbox in order to run your bot/scrape content. That's the bridge, and that's where untrusted content can run at the same privileges as the code itself.

Maybe you wouldn't need that... I'm assuming you are running some code outside of node server? This advice is really just top-of-the-head type stuff, so take it with a grain of salt. As I said before nothing will be secure, but you might be able to "harden" a bit. I've never used jsdom but it's a good sign that there is a sandbox there. I'd look carefully at the source code to understand how the sandbox is constructed.

You need to protect against calls made to nodejs. (There really is no way to do that, but some ideas to at least make it more secure are checking each call to localhost against a specific whitelist. IP/Port... you may also want to choose a randomized port for your listener.)

I think he's talking about a nation-state working at the ISP... not necessarily the ISP. For instance in the US we have the Utah Data Center: en.wikipedia.org/wiki/Utah_Data_Center

I would assume they collect everything, but they only look at certain people. This would be classified and protected by any guv'ment who collects it. They wouldn't throw stones that could also be thrown at them. So I think you're safe in this particular case. Probably depends on whether you've been labeled an "enemy of the state" and how tyrannical the guv'ment is. In any case, there will be politicians in your system who are also gay and would want to protect that information so the pool of people under surveilance would be smaller than "all gays". (IMO)

you may want to check out how Kazakhstan does it: bugzilla.mozilla.org/show_bug.cgi?id=1567114