Re: Forums.FreeBSD.org - SSL Issue?
On Fri, 15 May 2015 07:51:34 -0500, Mark Felder wrote: > On Fri, May 15, 2015, at 03:07, Ian Smith wrote: > > On Thu, 14 May 2015 17:32:53 +0200, Adam Major wrote: > > > Hello > > > > > > >> But I don't think disable TLS 1.0 is ok. > > > >> > > > > > > > > TLS 1.0 is dead and is even now banned in new installations according > > to > > > > the PCI DSS 3.1 standards. Nobody should expect TLS 1.0 to be > > supported > > > > by *any* HTTPS site now. > > > > > > Maybe is dead but is used in many old browser / software still used. > > > > > > In PCI DSS 3.1 merchants must remove SSL and TLS 1.0 to 30 June 2016. > > > (new installations "in theory" should not be built on TLS 1.0). > > > > > > So we have 1 year and FreeBSD forum is not e-commerce site ;) > > > > People seem determined to make sure freebsd forums are one of the first > > sites to ban TLS 1.0, as some sort of best-practice example. > > > > I admit my knowledge of TLS issues is scant. I'd like to know whether > > allowing TLS 1.0 - with fallback from later levels denied, as it already > > is - endangers the server, or only the client? If there's a clearly > > stated and immediate danger to the forum server, I can accept that, but > > I'd have thought https://www and svnweb would be more at such peril? > > Will there be any notice before they're denied TLS 1.0 access also? > The danger is decryption. Your username/password could be stolen if > someone captures your traffic after successfully initiating a downgrade > attack. So the danger is only to myself, from some MITM, and not to the server? And despite the forum cert setup shown at https://www.ssllabs.com/ssltest/analyze.html?d=forums.freebsd.org : Downgrade attack prevention Yes, TLS_FALLBACK_SCSV supported (more info) which refers to RFC 7507, https://datatracker.ietf.org/doc/rfc7507/ which I've read, are we not trusting that mechanisn to prevent some successful initiation of a downgrade attack - which I rather imprecisely called "with fallback from later levels denied" above? > You can't login to www.freebsd.org or svnweb. The most they can do is > see what you're browsing, which isn't private anyway. Alright. > > If it's just for making the sort of point that Mark is advocating, to > > force people to join this 'rolling automatic update' model so beloved of > > Microsoft and their captive hardware vendors, then I think doing that, > > without any sort of prior notice, is rather less than I've come to > > expect from the FreeBSD project over 17 years. > > > > But I'm a grandpa too; guess I have old-fashioned expectations :) > Microsoft has nothing to do with this. They're setting a good example. Alright, the leopard has changed its spots; wonders will never cease. > OSX is sort-of on that train too. FreeBSD has always been ahead of the > curve with the ports tree being a rolling-release model. We need the > Linux distros to get their heads on straight now, too. The latter should be simple enough :) > Just a reminder: I don't speak for the project in these matters. I'm > just telling you what best current practices are. I have no idea who > made that decision for the forums, or if it's even worth having the > forums on https anyway. Other forums I use allow http connections, read only, only requiring switching to https for login and thus posting, which is fair enough, and I have almost always only read a few forum posts, but see below .. Noone has yet seen fit to even comment on the matter of no prior notice; there is usually at least some heads-up warning, 'better upgrade now', before access is denied to some FreeBSD service from older browsers. > If it was up to me I probably wouldn't even put > https on the forums even though Google will penalize it in search > results. (Sure, you have a user account there... but it doesn't really > do anything... you're not using the same credentials everywhere are > you?) Of course not. And I just checked, being unsure I'd ever posted there, to find my password server-allocated anyway, so I must have posted once. > Actually, that might be the reason -- Google search results. Perhaps > Google is also logging what protocols/ciphers your HTTPS has and is > using that in search rankings. You're seriously suggesting that the FreeBSD project should set security policies to favour higher rankings from an advertising company? cheers, Ian ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Forums.FreeBSD.org - SSL Issue?
On 18 mai 2015, at 09:05, Ian Smith wrote: >> >> Actually, that might be the reason -- Google search results. Perhaps >> Google is also logging what protocols/ciphers your HTTPS has and is >> using that in search rankings. > > You're seriously suggesting that the FreeBSD project should set security > policies to favour higher rankings from an advertising company? There's a bigger picture. Google is promoting strong security. Using web sites HTTPS details (proto, ciphers, certificate trustworthiness...) as ranking parameter is an incentive for admin to switch to better protocol and stronger cipher suits (& more expensive certificates). Their next step, currently ongoing in fact, is to limit or even remove browser confidence in older protocol/ciphers, so that users would be deterred from visiting those web sites. Domain Validated certificates are probably a target to be shot dead in few years too. As an admin I find it to be a pain in the *** to constantly have to deal with latest Google "vision", but as a user I think they are right because that's the way to go for promoting strong crypto. regards, patpro ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Forums.FreeBSD.org - SSL Issue?
On Mon, May 18, 2015 at 09:43:24AM +0200, pat...@patpro.net wrote: > On 18 mai 2015, at 09:05, Ian Smith wrote: > > >> > >> Actually, that might be the reason -- Google search results. Perhaps > >> Google is also logging what protocols/ciphers your HTTPS has and is > >> using that in search rankings. > > > > You're seriously suggesting that the FreeBSD project should set security > > policies to favour higher rankings from an advertising company? > > > There's a bigger picture. Google is promoting strong security. Using web > sites HTTPS details (proto, ciphers, certificate trustworthiness...) as > ranking parameter is an incentive for admin to switch to better protocol and > stronger cipher suits (& more expensive certificates). > Their next step, currently ongoing in fact, is to limit or even remove > browser confidence in older protocol/ciphers, so that users would be deterred > from visiting those web sites. Domain Validated certificates are probably a > target to be shot dead in few years too. > > As an admin I find it to be a pain in the *** to constantly have to deal with > latest Google "vision", but as a user I think they are right because that's > the way to go for promoting strong crypto. As user I am don't need crypto, strong or weak. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Forums.FreeBSD.org - SSL Issue?
On Mon, May 18, 2015, at 02:05, Ian Smith wrote: > > > The danger is decryption. Your username/password could be stolen if > > someone captures your traffic after successfully initiating a downgrade > > attack. > > So the danger is only to myself, from some MITM, and not to the server? > And despite the forum cert setup shown at > https://www.ssllabs.com/ssltest/analyze.html?d=forums.freebsd.org : > > Downgrade attack prevention Yes, TLS_FALLBACK_SCSV supported (more > info) > > which refers to RFC 7507, https://datatracker.ietf.org/doc/rfc7507/ > which I've read, are we not trusting that mechanisn to prevent some > successful initiation of a downgrade attack - which I rather imprecisely > called "with fallback from later levels denied" above? > This is irrelevant to this conversation. with TLS_FALLBACK_SCSV, those with strong crypto keep strong crypto. Those with weak crypto are _still_ vulnerable to their traffic being decrypted. This new mechanism does not magically make their weak crypto more secure. > > > Microsoft has nothing to do with this. They're setting a good example. > > Alright, the leopard has changed its spots; wonders will never cease. > Troll detected. If by now in your adult life you haven't recognized that you need to use the right tool for the right job -- whether that be Windows, OSX, Linux, FreeBSD, OpenBSD, NetBSD, DragonflyBSD, SmartOS, Illumos, Solaris, etc etc etc -- I can't help you. It might surprise you that some FreeBSD developers use Windows as their daily OS. Many use OSX. > > Other forums I use allow http connections, read only, only requiring > switching to https for login and thus posting, which is fair enough, > and I have almost always only read a few forum posts, but see below .. > I agree that would be reasonable, but I am not involved in the forum administration -- or cluster, for that matter. > > > Actually, that might be the reason -- Google search results. Perhaps > > Google is also logging what protocols/ciphers your HTTPS has and is > > using that in search rankings. > > You're seriously suggesting that the FreeBSD project should set security > policies to favour higher rankings from an advertising company? > If people can't search Google and find results on the first page they're going to be very, very discouraged from even trying it out. I don't think I can provide any further information about what's going on here, but I hope that I've answered some questions about why this isn't such a terrible idea. Feel free to file a bug report if you would like this followed up by those who have control over these decisions. https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Services ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Forums.FreeBSD.org - SSL Issue?
On Sun, May 17, 2015, at 18:06, Dan Lukes wrote: > On 05/18/15 00:00, Mark Felder: > >> If TLS 1.0 is considered severe security issue AND system utilities are > >> using it, why there is no Security Advisory describing this system > >> vulnerability ? > >> > > > > It's not a vulnerability in software, it's weakness in the protocol > > design. > > Like protocol protocol downgrade triggered by MITM attack flaw or > protocol design flaw in session renegotiation support. The first one > addressed in FreeBSD-SA-14:23.openssl, the second one in > FreeBSD-SA-09:15.ssl > > So the "is it protocol flaw or implementation bug" seems not to be true > major criteria. > > OK, I wish I got best answer to my question possible. I'm not going to > discuss SA issuing policy in this thread. > FreeBSD-SA-14:23: primarily backported a new feature (TLS_FALLBACK_SCSV) to help prevent those with stronger crypto from being forced to downgrade to weak crypto via a MITM attack FreeBSD-SA-09:15: fixes some bugs dealing with potential MITM attacks Neither of these directly address a broken protocol, such as warning all users that "using SSL 3.0 or TLS 1.0 is dangerous" I mean, should we have an SA because our libc supports strcpy and people can use that and create severe vulnerabilities? Or the fact that there is no firewall enabled by default, so you should probably enable one? That seems a bit extreme. You could write a whole book and still not cover all of these topics :-) Hope that helps ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Forums.FreeBSD.org - SSL Issue?
On Mon, May 18, 2015 at 08:42:54AM -0500, Mark Felder wrote: > > > > > Actually, that might be the reason -- Google search results. Perhaps > > > Google is also logging what protocols/ciphers your HTTPS has and is > > > using that in search rankings. > > > > You're seriously suggesting that the FreeBSD project should set security > > policies to favour higher rankings from an advertising company? > > > > If people can't search Google and find results on the first page they're > going to be very, very discouraged from even trying it out. > > I don't think I can provide any further information about what's going > on here, but I hope that I've answered some questions about why this > isn't such a terrible idea. Feel free to file a bug report if you would > like this followed up by those who have control over these decisions. Need higher rankings with https? Do https mirrors for google/bing. Client can't use strong encription? Allow cleartext and weak encription. FreeBSD forum posts don't contains any sensitive information. "Be strict in what you send, but generous in what you receive" ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: pkg audit / vuln.xml failures
On 5/17/2015 4:02 PM, Roger Marquis wrote: > Does anyone know what's going on with vuln.xml updates? Over the last > few weeks and months CVEs and application mailing lists have announced > vulnerabilities for several ports that in some cases only showed up in > vuln.xml after several days and in other cases are still not listed > (despite email to the security team). > > Is there a URL outlining the policies and procedures of vuln.xml > maintenance? > ports-secteam@ owns this file, not secteam@. The team needs more help. Would you like to volunteer to submit vuxml updates? Many contributors, and committers, feel the file is not easy to contribute to. Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: pkg audit / vuln.xml failures
ports-secteam@ owns this file, not secteam@. Thanks for the pointer Bryan. I would hope that port vulnerability emails are forwarded from secteam@ to ports-secteam@, by policy, as the freebsd.org website is not clear on this. Either way at least I/we now know the right address/es. The team needs more help. Would you like to volunteer to submit vuxml updates? Many contributors, and committers, feel the file is not easy to contribute to. I have been submitting ports vulnerability updates and will continue to do so (now to ports-secteam@). If there are any open seats on ports-secteam I would like to contribute on that level as well. Still interested in the team's policies and procedures, if those are online somewhere. Roger Marquis ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Forums.FreeBSD.org - SSL Issue?
On 05/18/15 15:52, Mark Felder: I mean, should we have an SA because our libc supports strcpy and people can use that and create severe vulnerabilities? No, but we should have SA whenever other system component is using strcpy() the way that may affect system security. System utility 'fetch' is willing negotiate known-to-be-insecure protocol with no warning and by default. Sensitive user's data may be transferred by base system utility via insecure protocol. I consider it bug in fetch code. A system utility must not allow silent transfer of data via known insecure protocol if secure transfer has been requested. I see no reason to keep the issue in the dark, even in the case the issue will not be patched on 8-R & 9-R. OK, I'm former bank IT security officer, so I my expectations related to handling of security issues may be set so high. It seems there is nothing more to say about this (slightly off-)topic. I wish the vulnerability should be disclosed to public, you wish it is not necessary because it's known bug in a protocol design and users doesn't expect secure channel from 'fetch'. Two men, two opinions. It's not necessary to reach consent. Thank you for all comments and responses. Dan ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Forums.FreeBSD.org - SSL Issue?
On Mon, May 18, 2015, at 12:34, Dan Lukes wrote: > On 05/18/15 15:52, Mark Felder: > > I mean, should we have an SA because our libc supports strcpy and people > > can use that and create severe vulnerabilities? > > No, but we should have SA whenever other system component is using > strcpy() the way that may affect system security. > > System utility 'fetch' is willing negotiate known-to-be-insecure > protocol with no warning and by default. Sensitive user's data may be > transferred by base system utility via insecure protocol. I consider it > bug in fetch code. A system utility must not allow silent transfer of > data via known insecure protocol if secure transfer has been requested. > > I see no reason to keep the issue in the dark, even in the case the > issue will not be patched on 8-R & 9-R. OK, I'm former bank IT security > officer, so I my expectations related to handling of security issues may > be set so high. > > It seems there is nothing more to say about this (slightly off-)topic. I > wish the vulnerability should be disclosed to public, you wish it is not > necessary because it's known bug in a protocol design and users doesn't > expect secure channel from 'fetch'. > > Two men, two opinions. It's not necessary to reach consent. > > Thank you for all comments and responses. > > Dan > Fetch also doesn't have a certificate trust store out of the box. It's very dependent on the sysadmin to make good decisions. Much like Apache with mod_ssl will *accept* connections on SSLv3 unless you manually configure the protocols. FYI, you can set SSL_NO_SSL3 and SSL_NO_TLS1 in your env to stop this behavior in fetch. If you add this to your base system image you can lock this down pretty reliably. Keep in mind that changing this default behavior in fetch would be a POLA violation and possibly break scripts for countless users. Comparatively, is the forums HTTPS also a POLA violation? Maybe! I can't decide. :-( ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: pkg audit / vuln.xml failures
On Sun, May 17, 2015, at 16:02, Roger Marquis wrote: > Does anyone know what's going on with vuln.xml updates? Over the last > few weeks and months CVEs and application mailing lists have announced > vulnerabilities for several ports that in some cases only showed up in > vuln.xml after several days and in other cases are still not listed > (despite email to the security team). > > Is there a URL outlining the policies and procedures of vuln.xml > maintenance? > I am also interested. I know there is a desire to leverage CPE in the future, but I've seen CPE entries take weeks to show up. Our vuln.xml maintenance has always been pretty solid. Is there a lack of manpower right now? Are there notices/reports not being processed? How can we help? ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: pkg audit / vuln.xml failures
On 18 May 2015 at 19:06, Mark Felder wrote: > > > On Sun, May 17, 2015, at 16:02, Roger Marquis wrote: >> Does anyone know what's going on with vuln.xml updates? Over the last >> few weeks and months CVEs and application mailing lists have announced >> vulnerabilities for several ports that in some cases only showed up in >> vuln.xml after several days and in other cases are still not listed >> (despite email to the security team). >> >> Is there a URL outlining the policies and procedures of vuln.xml >> maintenance? >> > > I am also interested. I know there is a desire to leverage CPE in the > future, but I've seen CPE entries take weeks to show up. Our vuln.xml > maintenance has always been pretty solid. Is there a lack of manpower > right now? Are there notices/reports not being processed? > > How can we help? Bug reports with notice of new additions just to give a heads up at the least. Sevan / Venture37 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: pkg audit / vuln.xml failures
On Mon, May 18, 2015, at 14:01, Sevan / Venture37 wrote: > On 18 May 2015 at 19:06, Mark Felder wrote: > > > > > > On Sun, May 17, 2015, at 16:02, Roger Marquis wrote: > >> Does anyone know what's going on with vuln.xml updates? Over the last > >> few weeks and months CVEs and application mailing lists have announced > >> vulnerabilities for several ports that in some cases only showed up in > >> vuln.xml after several days and in other cases are still not listed > >> (despite email to the security team). > >> > >> Is there a URL outlining the policies and procedures of vuln.xml > >> maintenance? > >> > > > > I am also interested. I know there is a desire to leverage CPE in the > > future, but I've seen CPE entries take weeks to show up. Our vuln.xml > > maintenance has always been pretty solid. Is there a lack of manpower > > right now? Are there notices/reports not being processed? > > > > How can we help? > > Bug reports with notice of new additions just to give a heads up at the > least. > I was just thinking it might be nice when you're committing a change to a port to fix a CVE if there was a tag you can drop in the commit log to tell ports-security if there is a need for an entry to vuln.xml. At least those without experience editing vuln.xml can more easily have someone else assist them with getting it added. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Forums.FreeBSD.org - SSL Issue?
On 05/18/15 20:04, Mark Felder: Fetch also doesn't have a certificate trust store out of the box. fetch (nor SSL protocol itself) claim there is one here FYI, you can set SSL_NO_SSL3 and SSL_NO_TLS1 in your env to stop this behavior in fetch. If you add this to your base system image you can lock this down pretty reliably. I'm not using fetch for transfer of secure data at all. But yes, the countermeasures you described can be part of SA I'm calling for. Keep in mind that changing this default behavior in fetch would be a POLA violation and possibly break scripts for countless users. Comparatively, is the forums HTTPS also a POLA violation? Maybe! I can't decide. :-( If I will be called to decide between POLA to be violated and security to be violated, I will vote for POLA violation all the times. Security have higher priority to be maintained. I'm sure it's not necessary to compare possible damages for those two scenarios. And no broken user script may happen in advance. No system will change behavior unless upgraded to patched version by responsible admin. He should be allowed to configure patched system to start fetch in former "security violation" mode (but not by default) if it will fit better their wishes. I consider it better than silence about the issue. But to say true, it's not my war - and no one seems to be with me here ;-) I have own source repository with custom system patches so I'm not tied to "official" decisions. No offense to FreeBSD team in any way! I'm just not average user. ;-) Dan ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: pkg audit / vuln.xml failures
On 18 May 2015 at 20:26, Mark Felder wrote: > I was just thinking it might be nice when you're committing a change to > a port to fix a CVE if there was a tag you can drop in the commit log to > tell ports-security if there is a need for an entry to vuln.xml. At > least those without experience editing vuln.xml can more easily have > someone else assist them with getting it added. Ah, yes, that applies to those with those shiny commit bits. I'm on the other side. It certainly needs to be added to the workflow of updating/maintaining ports somehow. There's the problem of Maintaining the vuxml entries Flagging security issues resolved in updates Flagging unaddressed security updates Sevan / Venture37 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Forums.FreeBSD.org - SSL Issue?
On Mon, May 18, 2015, at 13:55, Dan Lukes wrote: > > I have own source repository with custom system patches so I'm not tied > to "official" decisions. No offense to FreeBSD team in any way! I'm just > not average user. ;-) > > Do not be discouraged about submitting them. It's quite easy to get eyes on them now with the Phabricator https://reviews.freebsd.org/ ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
