|
RFC2324 posted:Newer is not always better. Cool platitude but SMB2+ is definitely better and FTP permissions are garbage.
|
#
?
Jul 4, 2017 01:15
|
|
|
|
| # ? May 10, 2024 19:25 |
|
|
Furism posted:There's no network error. The browser can reach the resources just fine, the devs apparently just decided to block "subresource" downloads if the origin URI has credentials in it. I wish I had a thread but they don't provide one. Just a warning in the console with a link to a bug page. I don't care enough to look for one since I can just switch to Firefox to access the page, I simply find their handling of that change a little bit lacking. Blocking relative urls is a bug that they are fixing. https://bugs.chromium.org/p/chromium/issues/detail?id=731618 You can use --disable-blink-features=BlockCredentialedSubresources until then.
|
|
#
?
Jul 4, 2017 04:51
|
|
|
https://twitter.com/eric_capuano/status/882086249980448769
|
|
#
?
Jul 4, 2017 06:57
|
|
|
BangersInMyKnickers posted:Cool platitude but SMB2+ is definitely better and FTP permissions are garbage. I think he's referring to the printer being newer, but not better. Because, ya know. Printers.
|
|
#
?
Jul 4, 2017 15:23
|
|
|
Haven't seen this mentioned yet - Horcrux, a password manager for paranoid users. https://arxiv.org/pdf/1706.05085.pdf
|
|
#
?
Jul 6, 2017 15:58
|
|
|
Here come my terrible poasts:BangersInMyKnickers posted:Crypto Config Boogaloo 2017 Edition BangersInMyKnickers posted:I'm dropping DSA/DSS ciphers from servers because TLS1.3 goes RSA-only and your CA probably isn't issuing DSA certs anyway. Still on for clients for compatibility reasons.
|
|
#
?
Jul 6, 2017 16:36
|
|
|
Hey speaking of certs, https://twitter.com/letsencrypt/status/882985570401701888
|
|
#
?
Jul 6, 2017 17:21
|
|
|
anthonypants posted:Hey speaking of certs, https://twitter.com/letsencrypt/status/882985570401701888 
|
|
#
?
Jul 6, 2017 17:22
|
|
|
LetsEncrypt Wildcard Certificates™, Brought to you by the NSA
|
|
#
?
Jul 6, 2017 17:42
|
|
|
BangersInMyKnickers posted:LetsEncrypt Wildcard Certificates™, Brought to you by the NSA Oh no. Come on. From what I know LetsEncrypet changed a lot in a good way.
|
|
#
?
Jul 6, 2017 23:34
|
|
|
Bangers just doesn't like wild cards because they tempt people into sloppy key management practices or something. LE is pretty much the hardest US-based CA for intelligence to subvert, given how it's structured and staffed around transparency.
|
|
#
?
Jul 6, 2017 23:48
|
|
|
TBH I'd be okay with the NSA giving out free wildcards if it would mean people would finally stop doing logins and poo poo over plain HTTP. It's all about the Mossad/Not-Mossad threat model, and logins over plain HTTP falls squarely in the not-Mossad category.
|
|
#
?
Jul 7, 2017 00:20
|
|
|
Subjunctive posted:Bangers just doesn't like wild cards because they tempt people into sloppy key management practices or something. LE is pretty much the hardest US-based CA for intelligence to subvert, given how it's structured and staffed around transparency. If they enforce that common mistakes with wildcards don't happen on creation, it will certainly be heads above a lot of other registers.
|
|
#
?
Jul 7, 2017 00:34
|
|
|
BangersInMyKnickers posted:Here come my terrible poasts: Serious question: Why are the lovely NIST curves still above 25519? Most of the RFCs for it are either published or in the queue.
|
|
#
?
Jul 7, 2017 01:01
|
|
|
"In the queue" isn't really compelling in a lot of environments.
|
|
#
?
Jul 7, 2017 02:31
|
|
|
I don't like wildcard certs because they encourage lazy, sloppy practices but more HTTPS everywhere is a very good thing.
|
|
#
?
Jul 7, 2017 02:42
|
|
|
What's the problem with wildcard certs? Is it just the idea that if you have multiple domains then they're probably running on separate servers (physical or virtual) and compromising one shouldn't compromise the other, or is there something else to it?
|
|
#
?
Jul 7, 2017 04:33
|
|
|
vOv posted:What's the problem with wildcard certs? Is it just the idea that if you have multiple domains then they're probably running on separate servers (physical or virtual) and compromising one shouldn't compromise the other, or is there something else to it? A lot of systems involve one server being set up as aservice.whatever, a different one being anotherservice.whatever, and so on. The right way to set up that situation is to create one certificate for each service, and only distribute the corresponding keys to the servers that need them. Non-wildcard certificates encourage this, because standing up a service already involves getting a certificate signed for that domain. Wildcard certificates encourage people to be lazy, create a single wildcard certificate, and use the same key for every server. Wildcards can make sense in other situations, like if you're terminating all your ssl connections at the same load balancer anyway. But: - if you're doing that already, you're not the sort of organisation Let's Encrypt is targeting - if you're setting up ssl for the first time, you can just load-balance encrypted connections based on sni and do it the right way instead So this doesn't meaningfully help with ssl usage, while encouraging organisations to use broken processes instead of doing it right.
|
|
#
?
Jul 7, 2017 05:02
|
|
|
Honestly with the certbot tool I don't even understand why LE is doing this. It makes generating and installing new certificates The Right Way extremely easy and in that case I believe people are trading too much of security for convenience.
|
|
#
?
Jul 7, 2017 19:26
|
|
|
Furism posted:Honestly with the certbot tool I don't even understand why LE is doing this. It makes generating and installing new certificates The Right Way extremely easy and in that case I believe people are trading too much of security for convenience. Why are wildcards so bad?
|
|
#
?
Jul 7, 2017 19:41
|
|
|
Because slack shouldn't be allowed to generate domains like it does without instantly getting issued and deploying a new cert to all its https terminators. (Wild cards are fine.)
|
|
#
?
Jul 7, 2017 19:44
|
|
|
Methylethylaldehyde posted:Why are wildcards so bad? I think the tighter the certificates are, the less value each of them has. I think that's desirable but if a company has got top-notch security and is confident they can handle it then fine I guess. Subjunctive posted:Because slack shouldn't be allowed to generate domains like it does without instantly getting issued and deploying a new cert to all its https terminators. To be honest it'd be pretty easy to automate that. And in a SDN world pushing certs isn't a big deal.
|
|
#
?
Jul 7, 2017 19:46
|
|
|
Furism posted:To be honest it'd be pretty easy to automate that. And in a SDN world pushing certs isn't a big deal. Who is going to turn around issued certs sub-second (maybe LE, maybe)? When you enter your server name to create a server on slack, https://furismrocks.slack.com works instantly, it's part of the flow. I'm not sure how SDN affects cert deployment here, could you elaborate? I don't remember exactly how long it took to roll a new cert at Facebook, but it definitely wasn't fast.
|
|
#
?
Jul 7, 2017 19:51
|
|
|
I'll literally be using it to secure a lovely self-hosted webpage and possible my RDP-gateway server. Possibly an exchange instance if I decide I really do in fact hate myself.
|
|
#
?
Jul 7, 2017 19:51
|
|
|
Is anyone in here running an IDS/IPS setup on their home network? If so what's your setup like? I'm planning on moving forward with setting up a little home lab and monitoring traffic on my local lan as well as outside my firewall using Security Onion. Just need to pick up a new nic and more memory first.
|
|
#
?
Jul 8, 2017 02:15
|
|
|
Methylethylaldehyde posted:I'll literally be using it to secure a lovely self-hosted webpage and possible my RDP-gateway server. Possibly an exchange instance if I decide I really do in fact hate myself. For home use it doesn't loving matter at all. Your random home lab gear sharing a private key is not going to be the chink in the armor that brings your life crashing down.
|
|
#
?
Jul 8, 2017 05:16
|
|
|
https://www.youtube.com/watch?v=FUyaItsRInQ next gen
|
|
#
?
Jul 10, 2017 00:36
|
|
|
nope nope nope
|
|
#
?
Jul 10, 2017 00:38
|
|
|
It's all Juniper and WatchGuard for me from now on 
|
|
#
?
Jul 10, 2017 00:57
|
|
|
Internet Explorer posted:nope nope nope
|
|
#
?
Jul 10, 2017 02:19
|
|
|
Cylance is a load of bollocks, isn't it? The information I can get about it is horribly vague, but couple of our assistant directors are carrying on like it's a silver bullet for windows client security after going to a Dell pissup.
|
|
#
?
Jul 10, 2017 05:04
|
|
|
I don't know much about Cylance, but I remember reading this article, which raised an eyebrow. https://arstechnica.com/information-technology/2017/04/the-mystery-of-the-malware-that-wasnt/
|
|
#
?
Jul 10, 2017 05:06
|
|
|
Cylance is crap. If you go with them you'll never be able to talk about how much crap they are.
|
|
#
?
Jul 10, 2017 06:09
|
|
|
Lain Iwakura posted:Cylance is crap. If you go with them you'll never be able to talk about how much crap they are. Any software that comes with a complementary gag order is something you should avoid.
|
|
#
?
Jul 10, 2017 06:14
|
|
|
Fortinet devices are pretty good but god drat this is hard to watch.
|
|
#
?
Jul 10, 2017 07:19
|
|
|
My company decided to go ahead with Druva as a backup solution. Fine. Thing is, they configured the software so that every single file under the user profile is backed up. Being a systems engineer I have a lot of 4GB+ firmware files stored on my laptop for when I visit customers, need to connect to legacy systems to upgrade them, etc.. So overall I have around 400 GB worth of files, with only about 50 GB of files actually worth backing up (the rest being firmware files already on our CDN anyway). I complained about this (even with a 100 Mbps uplink at the office it's going to take forever to upload 400 GB - 5.2 years yesterday when I checked ; yeah I think Druva's side isn't super fast) and now IT tells me to store the files somewhere like C:\firmwares. I'm fairly sure that's against some recommended best practice from Microsoft and that the only place we should put files on a Windows systems is under C:\Users\<myUser>\. Is this just me imagining things or is it ok to store (non-confidential) files outside of my user's home?
|
|
#
?
Jul 11, 2017 09:46
|
|
|
Lain Iwakura posted:Cylance is crap. If you go with them you'll never be able to talk about how much crap they are. I was shocked that they are on VT now.
|
|
#
?
Jul 11, 2017 12:41
|
|
|
Furism posted:My company decided to go ahead with Druva as a backup solution. Fine. Thing is, they configured the software so that every single file under the user profile is backed up. Being a systems engineer I have a lot of 4GB+ firmware files stored on my laptop for when I visit customers, need to connect to legacy systems to upgrade them, etc.. So overall I have around 400 GB worth of files, with only about 50 GB of files actually worth backing up (the rest being firmware files already on our CDN anyway). I complained about this (even with a 100 Mbps uplink at the office it's going to take forever to upload 400 GB - 5.2 years yesterday when I checked ; yeah I think Druva's side isn't super fast) and now IT tells me to store the files somewhere like C:\firmwares. I'm fairly sure that's against some recommended best practice from Microsoft and that the only place we should put files on a Windows systems is under C:\Users\<myUser>\. I'm not sure about the recommended stuff, but we use Druva too. Every time I extract some big logs files I have to remember to use something like c:/logfiles or deal with annoying out of space alerts and emails for a few days too.
|
|
#
?
Jul 11, 2017 13:00
|
|
|
Furism posted:Is this just me imagining things or is it ok to store (non-confidential) files outside of my user's home? As long as the ACLs on these directories are configured according to your needs and any software that you have running does not go looking for these files elsewhere, sure go right ahead.
|
|
#
?
Jul 11, 2017 13:04
|
|
|
|
| # ? May 10, 2024 19:25 |
|
|
Furism posted:yeah I think Druva's side isn't super fast) and now IT tells me to store the files somewhere like C:\firmwares. I'm fairly sure that's against some recommended best practice from Microsoft and that the only place we should put files on a Windows systems is under C:\Users\<myUser>\. If you are asking from the "will this break anything" side, it's totally fine to place your files under some random root directory. If you're used to Linux et all, Windows basically mounts the hard disk whole, excepting some boot data that is totally transparent to the end user. While programs SHOULD look in the user's home directory, there's no need for them to do so. If this is a laptop that only you will use, there aren't permissions concerns to worry about here. From a "is this a nice thing to do" perspective it's a little gross but still very much the norm in many places.
|
|
#
?
Jul 11, 2017 13:41
|
|
