You got a lotta hate buddy
Hey what can I say… I got alotta hate so im dishing it out, gotta give back some how /s
I filled the gaps in my journal I wont need much to keep it going and adapt from here but jesus christ does webshit break a lot. We are just desensitized to it
just wait until I implement this when nginx updates since my nginx is always bleeding edge
I actually cant believe we are going to see the downfall of TCP (soon ™ ). Everything is going to binary encapsulation.
holy shit dude we could all optionally turn it on without hurting our existing configuration
we just have to advertise its available on what we know would work with it. So chrome and mozilla and android browser can go brrrrr (sorry ios)
I guess you could also do add_header Alt-Svc ‘HTTP/2=":443"’; as well
Why didnt I know about this. I will experiment this weekend. I like having options available for all. No reason to stay on a downgraded protocol if the client can support a new one and no reason to break HTTP/1.1 either
I fucking love these russian devs. The one thing the motherland did right other than wodka
Forgot to add this to the blog directory here:
Infrastructure Series -- Recursive DNS and Adblocking DoT w/NGINX
Yet another drop from my journal
I really am just making it electronic
Series 4: Infrastructure Series -- NGINX Reverse Proxy and Hardening SSL
A good amount of hardening and round robin multiple nginx load balancing can do pretty well
Checkout the rate limitng you can do. That and having a load balancer makes this more effective.
Im doing this now. Im also adding a second droplet for round robin load balancing and both will be optimized according to the docs for high loads
It makes taking it down harder. I dont need CF for that
error_log /var/log/nginx/$confName$port.log info;
That can really help store data you need to detect it too!
See my thread: (its long. Also go to the second post for my updated config) that might answer your questions
Infrastructure Series -- Recursive DNS and Adblocking DoT w/NGINX
Infrastructure Series -- Recursive DNS and Adblocking DoT w/NGINX - #16 by PhaseLockedLoop
I havent updated it for my DoH and DoT changes yet. The pihole setup is a simple filter. The unbound does all of the work. Ive also setup auth zones and hardened the DNSSEC of the unbound. I disabled DNSSEC on the pi to the unbound because there is no point since its local.
Use unbound + DNSSEC not pihole to unbound with DNSSEC. The lookup only matters on the unbound
My network itself is totally open I have a blog post lol: Phaselockedloopable- PLL's continued exploration of networking, self-hosting and decoupling from big tech
It is worrisome but thats the realization of an open source backend. Chromium can be forked and degoogled by anyone and its a better engine. FAR better code
Failure in leadership on the project tbch
Its fine thats why ive moved this discussion to my blog. LOL. See the top of this post
SEE! At one point in time you DID consider using CF in a very specific (and free) use-case… which is exactly what i continue to use it for. There are some decent free tier options, but all the points you made earlier in the previous thread remain valid.
On a side note… the SSLlabs stuff you dabbled in above, is there any value in adjusting what ciphers I’m using? I see your point, but I already managed to get an A+ despite not having things quite as fancy or elliptically curvy as you may:
Cipher Suites:
TLS 1.3 (suites in server-preferred order)
- TLS_AES_256_GCM_SHA384 (
0x1302
) ECDH x25519 (eq. 3072 bits RSA) FS 256 - TLS_CHACHA20_POLY1305_SHA256 (
0x1303
) ECDH x25519 (eq. 3072 bits RSA) FS 256 - TLS_AES_128_GCM_SHA256 (
0x1301
) ECDH x25519 (eq. 3072 bits RSA) FS 128
TLS 1.2 (suites in server-preferred order)
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (
0xc030
) ECDH x25519 (eq. 3072 bits RSA) FS 256 - TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (
0x9f
) DH 2048 bits FS 256
You don’t need to disable this. I just prefer to disable 192 and 128
Just gen a DH 4096 and be golden. You won’t have to regen that for a long time given perfect forward secrecy.
Disabling it was fairly easy. Do so in the openssl.conf globally
I went EC for efficiency. If I can muster sha512 over 256 I will because it’s also more efficient than 256
I also hardened my stuff because I realized I would be using DNS over TLS
and choosing the curve that the phone can run really easily AKA ChaCha 20 and keeping with the 256-bit scheme and having an AEAD setup
I knew that would probably be best for what I was doing You don’t necessarily need to do it and also because I know all the devices I’m using are very modern I wasn’t really worried about breaking backwards compatibility
Seeing as your server supports TLS 1.3, that should mean you have OpenSSL 1.1.1.
Might be worth getting rid of the DHE AES 256 for something like this: ECDHE-RSA-CHACHA20-POLY1305
I don’t have a super deep understanding of webservers and why one might want more than two cipher suites active, I just run as it works for me.
When I’m done with my exercise I think I can pull my SSL conf
It’s a dirty hack but it works for both of you and I so
If you scroll down on the SSL test you can actually go down and see if you’re vulnerable to anything that’s weak
You’ll have to scroll down quite a bit and expand most of the menu items
These type weak vulnerabilities?
Didn’t all quite fit on a page, probably should have tried to use Pastebin, i dunno. Sorry for the spam.
I’m not really married to any of these technologies, I’m just trying to learn a thing or two while I tinker and (hopefully) try to improve the computing experience for family and try to maintain those rigorous SLAs. >.<
Debian GNU/Linux 10 (buster)
OpenSSL 1.1.1d 10 Sep 2019
nginx version: nginx/1.18.0
This is just a little VM i run since migrating the web server off my RPi3B so I could repurpose that for a little ADS-B project attempting to learn a few basics about radio waves and the surrounding technology. The thinking was that it might better equip me to deal with WiFi related matters. Sorry, now I’m delving a bit further off topic. You guys are great.
then you fine but honestly all I did in openssl was this
Disclaimer im not resposible for broken systems
[default_conf]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
Options = ServerPreference,PrioritizeChaCha
Also everywhere I saw sha256
I changed to sha512
and anything RSA2048 to 4096
[ req ]
default_bits = 4096
default_md = sha512
Bingo and Im good
Also some other things I did were
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 19
challengePassword_max = 29
changed from 4 and 20
I keep churning it out man:
Series 5: Infrastructure Series -- Taking DNS One Step Further - Full DNS Server infrastructure
Apologies if I haven’t found it skimming through the thread but since I am now the owner of a Pixel 4a I’d like to follow your steps on getting the phone set up since my last lineageos setup was pretty tashy. Have you already written more specifically about what steps you took or could you if not?
The 4a isn’t officially supported. So my steps won’t be applicable until it gets supported.
The 5g version will take even longer.
Yeah I’ve seen that, my hope is that it overlaps greatly with the 4 though so I wouldn’t discount your steps being helpful or at least some general guidance.
It’s not the 5g version
Im NEVER