|
Shaggar posted:you were suggesting generating them on the fly instead of reusing existing keys. no, I was suggesting using wildcard certs, because slack can't predict what names they will need. if you go and create a slack community called "shaggarfanclub", then https://shaggarfanclub.slack.com" works moments later.
|
#
?
Jul 6, 2017 17:59
|
|
|
|
| # ? May 13, 2024 23:50 |
|
|
Thawte and Comodo both were at one point. I learned to stay away from wildcards a long time ago when I saw that. The documentation also encouraged you to mark the key as exportable when you added it to the server so it would be easier for you to pull the key pair out and copy it to every webserver in your environment
|
|
#
?
Jul 6, 2017 17:59
|
|
|
I don't understand that part. let's say the CA sends you a private key. you then have a private key in a file, just like if you'd generated it yourself. why would key management practices need to be different?
|
|
#
?
Jul 6, 2017 18:00
|
|
|
Slack's idiotic perversion of how DNS should be leveraged is their own problem and they can go gently caress themselves.
|
|
#
?
Jul 6, 2017 18:01
|
|
|
Subjunctive posted:no, I was suggesting using wildcard certs, because slack can't predict what names they will need. if you go and create a slack community called "shaggarfanclub", then https://shaggarfanclub.slack.com" works moments later. you were suggesting separate wild card certs (same domain, different key) instead of re-use which would require requesting new, identical wildcard certs with other keys. if you aren't doing this then you are re-using the keys and increasing your attack surface.
|
|
#
?
Jul 6, 2017 18:01
|
|
|
Subjunctive posted:I don't understand that part. let's say the CA sends you a private key. you then have a private key in a file, just like if you'd generated it yourself. why would key management practices need to be different? Because a wildcard cert cost hundreds or more per year so the pricing structure encouraged private key reuse. Again, I acknowledged that this issue goes away with pricing not being a factor but this was a traditional concern with wildcard certs
|
|
#
?
Jul 6, 2017 18:02
|
|
|
Shaggar posted:you were suggesting separate wild card certs (same domain, different key) instead of re-use which would require requesting new, identical wildcard certs with other keys. if you aren't doing this then you are re-using the keys and increasing your attack surface. oh, sure. just like you'd need to do to protect an alt-name version similarly, right? if you get the a|b|c|d|... key from one server you can see all traffic to all the servers, same as wildcard. Bangers was suggesting that you not share keys across servers, which means reissuing afaik.
|
|
#
?
Jul 6, 2017 18:03
|
|
|
Subjunctive posted:I don't understand that part. let's say the CA sends you a private key. you then have a private key in a file, just like if you'd generated it yourself. why would key management practices need to be different?
|
|
#
?
Jul 6, 2017 18:03
|
|
|
wyoak posted:concern would be that the CA has a copy of the private key you're using on your servers, I'd imagine the CA's would shy away from that just from a liability standpoint (although really nothing stupid a CA can do would surprise me at this point) what I've seen has been a web page that gives you something to copy. but the concern Bangers raised was around key management, not the CA keeping a copy for some reason (I sure wouldn't want to, in their position)
|
|
#
?
Jul 6, 2017 18:04
|
|
|
I would be *extraordinarily* surprised if LE's implementation asked for the private key, even if other CAs somewhere do or did, and we're talking about LE here
|
|
#
?
Jul 6, 2017 18:06
|
|
|
Subjunctive posted:oh, sure. just like you'd need to do to protect an alt-name version similarly, right? if you get the a|b|c|d|... key from one server you can see all traffic to all the servers, same as wildcard. Bangers was suggesting that you not share keys across servers, which means reissuing afaik. sure but with the wildcard its more likely to be re-used everywhere meaning more traffic is vulnerable to a leaked key. using alt names limits exposure. this is assuming you're installing these alt-name certs on clusters serving the same group of names vs having alt-name certs for every name you host across all clusters in every cert. in that case you're right its not much different from wildcards, but its also a bad idea.
|
|
#
?
Jul 6, 2017 18:10
|
|
|
Subjunctive posted:I would be *extraordinarily* surprised if LE's implementation asked for the private key, even if other CAs somewhere do or did, and we're talking about LE here yeah i doubt that that would be a thing. i have a few godad wildcard certs and they were all generated from CSRs
|
|
#
?
Jul 6, 2017 18:11
|
|
|
tl;dr: the primary benefit of lets encrypt was avoidance of key-reuse and wildcards and now they're gonna end that so w/e. its stupid but i guess just don't use them yourself.
|
|
#
?
Jul 6, 2017 18:16
|
|
|
Shaggar posted:tl;dr: the primary benefit of lets encrypt was avoidance of key-reuse and wildcards and now they're gonna end that so w/e. its stupid but i guess just don't use them yourself. the biggest benefit of LE was always easy free ssl certs that auto-renew avoidance of key reuse and wildcards was also good
|
|
#
?
Jul 6, 2017 18:25
|
|
|
Does LE force the client to generate a new private key after some interval or does it just keep rubber-stamping the same cert with new validity intervals until someone marks it as revoked or it ages out?
|
|
#
?
Jul 6, 2017 18:27
|
|
|
BangersInMyKnickers posted:Does LE force the client to generate a new private key after some interval or does it just keep rubber-stamping the same cert with new validity intervals until someone marks it as revoked or it ages out? certbot defaults to a new key, but if you want to live dangerously then you can reuse
|
|
#
?
Jul 6, 2017 18:30
|
|
|
*finger slowly slides toward the "smash dick and balls with hammer" button*
|
|
#
?
Jul 6, 2017 18:32
|
|
|
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. Oh yeah, extra thing to this: You may want to consider disabling DHE/DH ciphers on client OS's. There are at lot of DHE implementations out there that are only doing 512/1024-bit DH exchanges which is weak weak weak and their cipher preference order will put you on it regardless because on paper its better than something old like RSA_AES128. It's pretty safe to enable on servers since MS doesn't gently caress with those small key sizes and does 2048-out of box. ECDHE curves are much newer and more robust even with the low-end stuff like P256.
|
|
#
?
Jul 6, 2017 18:41
|
|
|
Subjunctive posted:no, I was suggesting using wildcard certs, because slack can't predict what names they will need. if you go and create a slack community called "shaggarfanclub", then https://shaggarfanclub.slack.com" works moments later. I wanna come back to this because I would like to know, what's the best way to handle something like this (user generated urls that you don't get to know in advance)? I get wildcard certs are bad and evil, but is the only other options really "URL gets submitted to you, and you manually update relevant certs"?
|
|
#
?
Jul 6, 2017 19:38
|
|
|
slack.com/shaggarfanclub would be a sane way to do it without having to fight with DNS and crypto infrastructure
|
|
#
?
Jul 6, 2017 19:42
|
|
|
https://www.forbes.com/sites/thomas...e/#334495f675ddquote:The data - which also included home and email addresses, birthdates, as well as customers' children's age ranges and genders where supplied - was sitting on an Amazon Web Services S3 server without username or password protection, Dyachenko said. It's likely the database was misconfigured by WWE or an IT partner as in other recent leaks on Amazon-hosted infrastructure. WWE said it was investigating.
|
|
#
?
Jul 6, 2017 20:01
|
|
|
come on, everyone knows wrestling data breaches are fake
|
|
#
?
Jul 6, 2017 20:04
|
|
|
BangersInMyKnickers posted:So with the RSA/DH PSK variants are you pre-sharing the asymm keys and then letting it negotiating the sym key from there while PSK_WITH_AES_256_GCM_SHA384 just pre-shares the symm key? I am concerned that the non-RSA/DH ciphers are doing something similar to these garbage anon suites through maybe that doesn't matter if you are assuming the out of band exchange was secure. The DHE ones use a pre-shared key to authenticate the DH key exchange. Because as you probably know DH does not offer authentication, only key exchange.
|
|
#
?
Jul 6, 2017 20:06
|
|
|
https://en.m.wikipedia.org/wiki/TLS-PSK
|
|
#
?
Jul 6, 2017 20:07
|
|
|
Subjunctive posted:no, I was suggesting using wildcard certs, because slack can't predict what names they will need. if you go and create a slack community called "shaggarfanclub", then https://shaggarfanclub.slack.com" works moments later. at slack's scale i am a little surprised they don't have an intermediate CA in order to issue trusted certificates on the fly it's expensive as hell to make that happen but slack has got a lot of fuckin money
|
|
#
?
Jul 6, 2017 20:22
|
|
|
Avenging_Mikon posted:I wanna come back to this because I would like to know, what's the best way to handle something like this (user generated urls that you don't get to know in advance)? I get wildcard certs are bad and evil, but is the only other options really "URL gets submitted to you, and you manually update relevant certs"? doesnt have to be manual. you can automate the process of getting a cert from LE and pushing it to whatever handles your tls termination in under a minute
|
|
#
?
Jul 6, 2017 20:38
|
|
|
Notorious b.s.d. posted:at slack's scale i am a little surprised they don't have an intermediate CA in order to issue trusted certificates on the fly I don't think Facebook has one either. running a CA loving sucks. LE spent less than $2M on their chained root, IIRC. it's not the money that's a barrier. even if you issue trusted certs on demand, you also have to deploy them in real time too and at scale that is unpleasant. I forget how long it took to roll an updated cert set to across FB, but it wasn't fast
|
|
#
?
Jul 6, 2017 21:19
|
|
|
Rufus Ping posted:doesnt have to be manual. you can automate the process of getting a cert from LE and pushing it to whatever handles your tls termination in under a minute
|
|
#
?
Jul 6, 2017 21:23
|
|
|
that's not wrong 
|
|
#
?
Jul 6, 2017 21:30
|
|
|
I don't get why there's not some way for me to get a restricted CA cert that can only sign certs for my own domain(s). There are features in X.509 to support doing that, but I'm not aware of any implementations actually checking for that nor any global CAs that will sign such a thing. It seems like that would be the correct solution, providing almost all the same flexibility as wildcards while potentially reducing the risk. Obviously if used poorly the risk could be equally bad as, but not worse than a wildcard cert.
|
|
#
?
Jul 6, 2017 21:41
|
|
|
there are issues with the current specifications of those extensions, IIRC, but also until all clients honor it you don't get anything from using them. I forget the details, but we decided back in 2011 that it wasn't worth putting in Firefox because we didn't want people implementing it as specified. I sure wish we'd had it for CNNIC though.
|
|
#
?
Jul 6, 2017 21:50
|
|
|
Zamujasa posted:come on, everyone knows wrestling data breaches are fake Nice!!
|
|
#
?
Jul 6, 2017 21:55
|
|
|
https://twitter.com/taviso/status/883070732573392897 
|
|
#
?
Jul 6, 2017 22:11
|
|
|
i opened the thread on phone and seeing twitter/taviso made me reflectorily go "oh poo poo"
|
|
#
?
Jul 6, 2017 22:16
|
|
|
god dammit
|
|
#
?
Jul 6, 2017 22:17
|
|
|
that's our tavis!
|
|
#
?
Jul 6, 2017 22:17
|
|
|
Subjunctive posted:there are issues with the current specifications of those extensions, IIRC, but also until all clients honor it you don't get anything from using them. I forget the details, but we decided back in 2011 that it wasn't worth putting in Firefox because we didn't want people implementing it as specified. If I'm not mistaken, isn't there a "critical" flag which tells clients to reject the cert if they don't understand it? It seems to me like there would still be a benefit from being able to do such things even if the services using those certs are only accessible by modern clients. My personal domains are only being accessed by myself and my friends who are generally tech-savvy, and at least the one business domain on which I'd really like this capability is also only accessed by devices I control. Interesting regarding the issues with the spec, I'm going to have to do some reading.
|
|
#
?
Jul 6, 2017 22:24
|
|
|
why doesnt this guy ever find earthshattering oh-poo poo vulns on like, monday morning or something always like thursday or friday afternoon
|
|
#
?
Jul 6, 2017 22:42
|
|
|
Arcsech posted:why doesnt this guy ever find earthshattering oh-poo poo vulns on like, monday morning or something i imagine he gets lame work poo poo out of the way, although he should have a p interesting for himself job, and then just hobbies away at whatevers the target
|
|
#
?
Jul 6, 2017 22:45
|
|
|
|
| # ? May 13, 2024 23:50 |
|
|
cinci zoo sniper posted:i imagine he gets lame work poo poo out of the way, although he should have a p interesting for himself job, and then just hobbies away at whatevers the target a lot of his job is sending email to people who have done, and likely will continue to do, dangerously stupid things
|
|
#
?
Jul 6, 2017 23:27
|
|