similar to: https and self signed

On Thu, June 16, 2016 14:23, Valeri Galtsev wrote: > > On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote: >> >> I doubt that most users check the dates on SSL certificates, >> unless they are familiar enough with TLS to understand that >> a shorter validity period is better for security. > > Oh, this is what he meant: Cert validity period. Though I agree >

On 06/20/2016 07:47 AM, James B. Byrne wrote: > On Sat, June 18, 2016 18:39, Gordon Messmer wrote: > >> I'm not interested in turning this in to a discussion on epistemology. >> This is based on the experience (the evidence) of some of the world's >> foremost experts in the field (Akamai, Cisco, EFF, Mozilla, etc). > Really? Then why did you forward your reply a

On Mon, June 20, 2016 13:16, Gordon Messmer wrote: > On 06/20/2016 07:47 AM, James B. Byrne wrote: >> On Sat, June 18, 2016 18:39, Gordon Messmer wrote: >> >>> I'm not interested in turning this in to a discussion on >>> epistemology. >>> This is based on the experience (the evidence) of some of the >>> world's foremost experts in the

On Sat, June 18, 2016 18:39, Gordon Messmer wrote: > On 06/18/2016 02:49 PM, James B. Byrne wrote: >> On Fri, June 17, 2016 21:40, Gordon Messmer wrote: >>> https://letsencrypt.org/2015/11/09/why-90-days.html >> With respect citing another person's or people's opinion in support >> of >> your own is not evidence in the sense I understand the word to

On Fri, June 17, 2016 12:31, Valeri Galtsev wrote: > > On Fri, June 17, 2016 10:19 am, James B. Byrne wrote: > >> Keys issued to individuals certainly should have short time limits >> on them. In the same way that user accounts on systems should >> always have a near term expiry date set. People are careless. >> And their motivations are subject to change. >

On 06/18/2016 02:49 PM, James B. Byrne wrote: > On Fri, June 17, 2016 21:40, Gordon Messmer wrote: >> https://letsencrypt.org/2015/11/09/why-90-days.html > With respect citing another person's or people's opinion in support of > your own is not evidence in the sense I understand the word to mean. I'm not interested in turning this in to a discussion on epistemology.

On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote: > On 06/16/2016 10:53 AM, Walter H. wrote: >> lets encrypt only trusts for 3 months; would you really except in an >> onlineshop, someone trusts this shop? >> let us think something like this: "when the CA only trusts for 3 >> months, how should I trust for a longer period >> which is important for warranty

On Sat, June 18, 2016 7:52 am, Always Learning wrote: > > On Fri, 2016-06-17 at 15:56 +0100, Michael H wrote: > >> On 17/06/16 15:46, James B. Byrne wrote: > >> > >> > We operate a private CA for our domain and have since 2005. We >> > maintain a public CRL strictly in accordance with our CPS and have our >> > own OID assigned. Our CPS and

On Fri, June 17, 2016 11:06, Walter H. wrote: > On 17.06.2016 16:46, James B. Byrne wrote: >> On Thu, June 16, 2016 13:53, Walter H. wrote: >>> On 15.06.2016 16:17, Warren Young wrote: >>>> but it also affects the other public CAs: you can???t get a >>>> publicly-trusted cert for a machine without a publicly-recognized >>>> and -visible

Hello, yesterday one of the extensions on my asterisk server got compromised by brute-force attack. The attacker used it to try pull an identity theft scam playing a recording from a bank "your account has been blocked due to unusual activity, please call this number..." Attacker managed to make lots of calls for around 8 hours before I detected it and changed the password for that

On 17/06/16 15:46, James B. Byrne wrote: > > On Thu, June 16, 2016 13:53, Walter H. wrote: >> On 15.06.2016 16:17, Warren Young wrote: >>> but it also affects the other public CAs: you can???t get a >>> publicly-trusted cert for a machine without a publicly-recognized >>> and -visible domain name. For that, you still need to use >>> self-signed

On Fri, 2016-06-17 at 15:56 +0100, Michael H wrote: > On 17/06/16 15:46, James B. Byrne wrote: > > > > We operate a private CA for our domain and have since 2005. We > > maintain a public CRL strictly in accordance with our CPS and have our > > own OID assigned. Our CPS and CRL together with our active, expired > > and revoked certificate inventory is

On Fri, June 17, 2016 13:08, Valeri Galtsev wrote: > > We do not expire accounts until the person leaves the Department > and grace period passes. Then we do lock account and after some > time person's files are being deleted. This is the policy, and > this is what we do. The only time when account expiration is being > set is for undergraduate students who temporarily work

I see many entries in /var/log/secure similar to these: . . . /var/log/secure.1:Dec 31 08:00:55 gway01 sshd[7220]: Received disconnect from 93.89.144.31: 11: Bye Bye /var/log/secure.1:Dec 31 08:00:58 gway01 sshd[7221]: Failed password for root from 93.89.144.31 port 60100 ssh2 /var/log/secure.1:Dec 31 08:00:58 gway01 sshd[7222]: Received disconnect from 93.89.144.31: 11: Bye Bye

On Thu, June 16, 2016 13:53, Walter H. wrote: > On 15.06.2016 16:17, Warren Young wrote: >> but it also affects the other public CAs: you can???t get a >> publicly-trusted cert for a machine without a publicly-recognized >> and -visible domain name. For that, you still need to use >> self-signed certs or certs signed by a private CA. >> > A private CA is the

On 08/10/2017 04:41 PM, Frank-Ulrich Sommer wrote: > I can't see any security advantages of a self signed cert. I then you fail to understand the history, like when Microsoft's certs were undermined because the third party authentication agency gave the keys to 2 guys that knocked on the door and asked for them... -- So many immigrant groups have swept through our town that

On 06/16/2016 10:53 AM, Walter H. wrote: > lets encrypt only trusts for 3 months; would you really except in an > onlineshop, someone trusts this shop? > let us think something like this: "when the CA only trusts for 3 > months, how should I trust for a longer period > which is important for warranty ..." I doubt that most users check the dates on SSL certificates,

Message-ID: <479F2A63.2070408 at centos.org> On: Tue, 29 Jan 2008 07:30:11 -0600, Johnny Hughes <johnny at centos.org> Subject Was: [CentOS] Unknown rootkit causes compromised servers > > SOME of the script kiddies check higher ports for SSH *_BUT_* I only see > 4% of the brute force attempts to login on ports other than 22. > > I would say that dropping brute force

On Tue, Jul 28, 2015 at 6:32 PM, Warren Young <wyml at etr-usa.com> wrote: > On Jul 28, 2015, at 4:37 PM, Nathan Duehr <denverpilot at me.com> wrote: >> Equating this to ?vaccination? is a huge stretch. > > Why? It's not just an imperfect analogy it really doesn't work on closer scrutiny. Malware itself is not a good analog to antigens. Vaccinations provide

On Wed, September 23, 2015 00:11, Always Learning wrote: > > > That is great. When I started on Linux that was one of the very > first things I did. Every machine, including servers, has port 22 > replaced by a unique alternative port. Port 22 is also blocked in > IPtables. > > There is an army of dangerous nutters attempting to break-in to > everything. They often mask