moonshine is...... posted:

Regarding the whole ISP's selling browsing history etc, I'm seeing a lot of people recommend a VPN as a solution. What keeps the ISP from just MITMing your traffic?

Truga posted:

Disgusting abuse of your power! You are punishing 30,000 websites, 99.9%+ of whom are completely legitimate, in order to exact revenge against Symantec.

LEAVE THE INNOCENT BYSTANDERS ALONE!!!!

I propose you block all *new* Symantec certificates until they go back and re-validate (AT THEIR EXPENSE) all the 30,000 websites, and revoke any that are found incorrect.

Be responsible with the power you have, and mindful of the massive collateral damage your actions cause!

You've already just destroyed wosign and startssl wreaking havoc across their entire user base: ***WE*** SUFFER when *you* attack CAs... so STOP IT!!!!

moonshine is...... posted:

Regarding the whole ISP's selling browsing history etc, I'm seeing a lot of people recommend a VPN as a solution. What keeps the ISP from just MITMing your traffic?

Wiggly Wayne DDS posted:

Execute just bad guy, don't commit genocide!!!

Wiggly Wayne DDS posted:

I fail to see anything relevant you've said? Yes - we are all mad at Symantec, and random google vigilante-employees want to cause extreme pain and damage to that company: fair enough.

However: screwing over 30,000+ innocent bystanders IS NOT THE WAY TO DO IT.

The startcom issue was just one naughty certificate; the destruction of all startcom user websites (including mine) was a decision google made to punish startcom for lying about their business relationship with wosign. This severely hurt huge numbers of innocent bystanders again, caused irrevocable damage (no other CA offers unlimited wildcard SANs) and massive costs (startcom were 10x+ less expensive that the greedy big American CAs ripping us all of $millions for nothing more than a few DNS lookups and crypto operations).

I'm not supporting Symantec, and not supporting startcom either.

I'm asking that you figure out who the bad guy is, and stop punching us instead of them. The Google fist is a one-punch killer. Be ***responsible*** with how you wield that power. Execute just bad guy, don't commit genocide!!!

moonshine is...... posted:

Regarding the whole ISP's selling browsing history etc, I'm seeing a lot of people recommend a VPN as a solution. What keeps the ISP from just MITMing your traffic?

Wiggly Wayne DDS posted:

The startcom issue was just one naughty certificate; the destruction of all startcom user websites (including mine) was a decision google made to punish startcom for lying about their business relationship with wosign.

stoopidmunkey posted:

I (very likely) could be wrong, but wouldn't using a non-your-isp dns server get around this? I use opendns' public servers and was hoping it would protect me since they wouldn't see my dns queries which are the most likely first thing anyone would look at.

they can still get records from opendns, but it makes it a little harder since it's a separate warrant and may not even apply as opendns is not an isp, just a dns service.

Wiggly Wayne DDS posted:

I'm asking that you figure out who the bad guy is, and stop punching us instead of them. The Google fist is a one-punch killer. Be ***responsible*** with how you wield that power. Execute just bad guy, don't commit genocide!!!

ate all the Oreos posted:

they can see your IP addresses that you're connecting to which is just as good for basically all the sites that matter

e: oh you mean over the VPN? yeah generally you use a different DNS server than your ISP's if you're going over a VPN for that reason

McGlockenshire posted:

symmantec can't tell a bad cert from not-bad certs because the flaws were one in execution of process, not a technical issue. symmantec literally can not pull just the bad certs because they didn't keep track of the process that was going wrong. symmantec keeps loving up, so it's time to drop the hammer.

Wiggly Wayne DDS posted:

Hard to tell if you're just trolling now.

Lets look at the big picture here: it's highly unlikely that even one single Symantec cert will ever cause harm to anyone.

But that's not the point:

Attacking a teeny minority of PERFECTLY HONEST websites because you disagree with their CA's procedures is not about protecting users. It's about punishing Symantec but causing their customers the greatest amount of pain possible.

Zero customers need to hurt here.

If google wanted - they could make Symantec fix the problem. The argument is over issuance procedures: make them RE DO those procedures in an audited an compliant way. Problem fixed: no collateral damage caused.

It appears like someone does not want to do that though: they want to cause the maximum pain, and are disguising their vindictive attack under the fake banner of "protect users".

However: screwing over 30,000+ innocent bystanders IS NOT THE WAY TO DO IT.

Look in a mirror: that's an evil bully staring back at you. You know full well this can be fixed without hurting customers, if google wanted to.

OSI bean dip posted:

this is an e-mail a colleague got

vOv posted:

i don't know the current state of dns encryption so it's also possible they could just read your DNS queries (unless you send those over your VPN)

OSI bean dip posted:

this is an e-mail a colleague got

flakeloaf posted:

do you like me

[ ] yes
[ ] no

OSI bean dip posted:

this is an e-mail a colleague got

moonshine is...... posted:

Regarding the whole ISP's selling browsing history etc, I'm seeing a lot of people recommend a VPN as a solution. What keeps the ISP from just MITMing your traffic?

vOv posted:

of course the real question is how to find a VPN you can trust

infernal machines posted:

yeah, you're basically trusting that your vpn provider, or the vps host you use if you roll your own, is not selling your traffic instead

some rando eastern european outfit offering service for $3/mo. is probably not going to be particularly well vetted

BiohazrD posted:

never heard of them, $8 a year is crazy. im using LE for my home certs but if i wasnt....

akadajet posted:

get 5 bux for re-enabling flash lol

akadajet posted:

get 5 bux for re-enabling flash lol

Wiggly Wayne DDS posted:

Hard to tell if you're just trolling now.

Lets look at the big picture here: it's highly unlikely that even one single Symantec cert will ever cause harm to anyone.

But that's not the point:

Attacking a teeny minority of PERFECTLY HONEST websites because you disagree with their CA's procedures is not about protecting users. It's about punishing Symantec but causing their customers the greatest amount of pain possible.

Zero customers need to hurt here.

If google wanted - they could make Symantec fix the problem. The argument is over issuance procedures: make them RE DO those procedures in an audited an compliant way. Problem fixed: no collateral damage caused.

It appears like someone does not want to do that though: they want to cause the maximum pain, and are disguising their vindictive attack under the fake banner of "protect users".

However: screwing over 30,000+ innocent bystanders IS NOT THE WAY TO DO IT.

Look in a mirror: that's an evil bully staring back at you. You know full well this can be fixed without hurting customers, if google wanted to.

apseudonym posted:

Source your quotes

quote:

At Symantec, we are proud to be one of the world’s leading certificate authorities. We strongly object to the action Google has taken to target Symantec SSL/TLS certificates in the Chrome browser. This action was unexpected, and we believe the blog post was irresponsible. We hope it was not calculated to create uncertainty and doubt within the Internet community about our SSL/TLS certificates.

Google’s statements about our issuance practices and the scope of our past mis-issuances are exaggerated and misleading. For example, Google’s claim that we have mis-issued 30,000 SSL/TLS certificates is not true. In the event Google is referring to, 127 certificates – not 30,000 – were identified as mis-issued, and they resulted in no consumer harm. We have taken extensive remediation measures to correct this situation, immediately terminated the involved partner’s appointment as a registration authority (RA), and in a move to strengthen the trust of Symantec-issued SSL/TLS certificates, announced the discontinuation of our RA program. This control enhancement is an important move that other public certificate authorities (CAs) have not yet followed.

While all major CAs have experienced SSL/TLS certificate mis-issuance events, Google has singled out the Symantec Certificate Authority in its proposal even though the mis-issuance event identified in Google’s blog post involved several CAs.

We operate our CA in accordance with industry standards. We maintain extensive controls over our SSL/TLS certificate issuance processes and we work to continually strengthen our CA practices. We have substantially invested in, and remain committed to, the security of the Internet. Symantec has publicly and strongly committed to Certificate Transparency (CT) logging for Symantec certificates and is one of the few CAs that hosts its own CT servers. Symantec has also been a champion of Certification Authority Authorization (CAA), and has asked the CA/Browser Forum for a rule change to require that all certificate authorities explicitly support CAA. Our most recent contribution to the CA ecosystem includes the creation of Encryption Everywhere, our freemium program, to create widespread adoption of encrypted websites.

We want to reassure our customers and all consumers that they can continue to trust Symantec SSL/TLS certificates. Symantec will vigorously defend the safe and productive use of the Internet, including minimizing any potential disruption caused by the proposal in Google’s blog post.

We are open to discussing the matter with Google in an effort to resolve the situation in the shared interests of our joint customers and partners.

OSI bean dip posted:

anthonypants posted:

rackspace requires you to pay $20/month for the privilege of turning ssl on

my goth gf posted:

hahaha what the gently caress

CrazyLittle posted:

probably charging for assigning a public ip

anthonypants posted:

I was having trouble setting up RANCID, and their documentation sucks rear end, so I thought I'd look at alternatives, and came across rConfig. It has a native web interface, and my coworkers hate Linux, so I thought I'd give it a look. Here's a few problems:
1) The install method is to download and run an installer script at http://rconfig.com/downloads/scripts/install_rConfig.sh. This script is a wrapper to determine if you have CentOS 6 or CentOS 7. You can get to this file over https, but then the script calls http://www.rconfig.com/downloads/scripts/centos7_install.sh or http://www.rconfig.com/downloads/scripts/centos6_install.sh, depending on what version of CentOS you have. I'm only going to bother with the CentOS 7 version, but I don't think there's going to be that much of a difference.
2) The next thing it does is install wget. Through yum, thankfully. Then it downloads http://www.rconfig.com/downloads/scripts/login.sh and moves it to /etc/profile.d/.
3) Then it disables SELinux by modifying /etc/selinux/config and changing 'enforcing' to 'disabled'. It then checks to see if it's set to disabled, and if it's set to permissive, this part of the script will probably fail. A backup of the original /etc/selinux/config is not saved.
4) /etc/sudoers is modified to allow the apache user access to disable requiring tty, and also allowing access to the crontab, zip, chmod, chown, whoami, wc, tail, and rm commands without a password.
5) The firewalld service is disabled and stopped. The iptables service is stopped.
6) The following repos are installed:
- epel-release, via yum install
- http://rpms.famillecollet.com/enterprise/remi-release-7.rpm, via rpm -Uvh
- https://mirror.webtatic.com/yum/el7/webtatic-release.rpm, via rpm -Uvh
- http://repo.mysql.com/mysql-community-release-el7-5.noarch.rpm, via rpm -Uvh
- https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm, via rpm -Uvh
- http://mirror.cogentco.com/pub/linux/epel/6/i386/epel-release-6-8.noarch.rpm, via rpm -ivh
7) The epel and remo repos are used to install httpd. wget is installed again. mlocate, attr, open-vm-tools, tree, the Development Tools group, ntp, sudo, telnet, bind-utils, traceroute, tree, unzip, vixie-cron, crontabs, openssl-devel, openssl, mod_ssl, vsftpd, mysql-server, mysql, mod_auth_mysql, mysql-devel, php70w-devel, php70w, php70w-gd, php70w-mbstring, php70w-mysql, php70w-pear, php70w-cli, php70w-common, and php70w-pdo are installed via yum.
8) ntp, httpd, mysqld, vsftpd, and crond are enabled and started.
9) vsftp is configured. The original /etc/vsftpd/vsftpd.conf is preserved as /etc/vsftpd/vsftpd.conf.original. The user is given the option to allow the root user access to connect over FTP.
10) ntp is configured. The user is given the option to define an ntp server, or it can use time.nist.gov.
11) The file http://www.rconfig.com/downloads/scripts/centos7_postReboot.sh is downloaded. The user is asked to reboot after the following step and run this script.
12) mysql_secure_installation is run.
13) The user reboots, and runs the post-reboot script.
14) http://www.rconfig.com/downloads/rconfig-3.6.7.zip is downloaded and unzipped into /home, creating /home/rconfig, and the apache user is assigned recursive ownership of the folder.
15) /etc/httpd/conf/httpd.conf is moved to /etc/httpd/conf/httpd.conf.original, and a new httpd.conf is moved in its place. Apache is restarted.
16) /etc/php.ini is configured. Apache is restarted.
17) SELinux is checked again by looking for a 'dot' at the end of the permissions list in ls -ahl, and if it finds one, it modifies every folder in the /home directory by removing the security.selinux attribute with setfattr.
18) The user is prompted to go to https://$hostname/install to finish the installation. /home/rconfig gets chowned to the apache user again, and any shell scripts in /home are removed.

Miscellaneous comments:
You have to sign up to get the link to the download script or any installation documentation. They have a GitHub and a more recent version is allegedly in development, but it wasn't immediately clear how to deploy that, so I just went with the stable version.
When you register, they send you an email address with your username and password in it. You cannot change your password.
They have an SSL cert for www.rconfig.com, but it expired in November of last year. They're using Let's Encrypt, so there's really no reason why they can't get it renewed, or why they can't also get one for rconfig.com. Some of their other domains also have expired certs.
There are a lot of hardcoded progress bars that don't actually do anything. Like, here's one from the first installer script, but there's one of these in almost every section of each script:

code:

OSMSG="Checking CentOS version..."
sleep 1
echo $OSMSG;
echo -ne '#####                     (33%)\r'
sleep 1
echo -ne '#############             (66%)\r'
sleep 1
echo -ne '##########################(100%)\n'
# Get major CentOS version 6 or 7
OSVERSION=$(rpm -qa \*-release | grep -Ei "oracle|redhat|centos" | cut -d"-" -f3)
etc.

With all of this in mind, I do not believe we will be using this product after all.