Search the Community

So I just instlled True NAS on my Server + Nextcloud Jail. Works like a charm, but I just cant seem to get HTTPS to work. I have tried different tutorials online for at least 10 hours, but nothing works. I have: -Public IPv4 -Opened Ports for HTTP and HTTPS -Registered Domain -Reachable Nextcloud (HTTP only) Tutorial I have tried: https://www.truenas.com/community/threads/enable-lets-encrypt-ssl-in-nextcloud-on-freenas.78734/ https://drive.google.com/file/d/1E68zif8k6V70KBqMGS09Xp_-eGb-RquX/view# https://www.youtube.com/watch?v=g1mYxrxdJXM https://www.youtube.com/watch?v=6nkN4MbsXls&t=140s https://www.youtube.com/watch?v=hxSAGY5zRwQ&t=321s How important is SSL encryption for private Nexcloud usage really? Because I think Im ready to say fuck it and not encrypt the server at all

Hello, I am trying to enable HTTPS for remote access which requires a SSL certificate. To do this I have been using Caddy but I'm open to using something else. Currently my setup is an Ubuntu Server and I use Docker+Portainer for Jellyfin. I am new to servers so I can't figure how to do this. I can't seem to find any tutorials and I am a little confused by the documentation on Jellyfin's website.

Hey guys, I know this isn't exactly a PC problem, but I'm having some trouble with a NAS I just set up; and I could really use some help. I'm new to working on networks, so please bear with me on this. After running out of storage space on my PC, I built a NAS to act as my own personal cloud server for my files. Setting up the unit was easy, but considering that it's gonna hold the bulk of my personal files and data, I wanted to set its security up properly before I headed back off to college without it. First, I tried to encrypt the connection by using Synology's "Let's Encrypt" feature to set up HTTPS. My first go at it actually worked pretty well. I followed Synology's own tutorial on it, and everything seemed to be working smoothly for about a week or so. But, after trying to transfer some files to the NAS, I noticed that the upload speed from my local PC was painfully slow. It was only using one ethernet port to transfer the files; even though I had two plugged into the back of the NAS. So, after some research, I figured out how to use Synology's "Link Aggregation" tool to bond the ports together for sharing the load and adding redundancy. And that's when the problems started showing up. My NAS's HTTPS configuration seemed to disappear the moment I logged back in. The synology.me domain name I set up failed to connect at all. And now the only way for me to get back into my own server is by using Quickconnect. I tried reaching out to Synology's IT service three times, but I kept getting put on hold for so long that the phone call would time out and hang itself up. And even a few weeks later, they still haven't emailed me back on the support ticket I left with them! I really want to set HTTPS back up in order to better protect my NAS. But, considering that my NAS will stay home and I'll be at school; the LAST thing I'd want is to loose access to all my data because one port failed. Is there anything I can do to try and fix it so both features can still run together? NAS build specs: NAS Enclosure: Synology DS 920+ x1 HDD: WD Red Plus 10 TB NAS Hard Disk Drive x1 SSD Cache: Seagate IronWolf 510 960GB NAS M.2 Internal Solid State Drive x1 RAM upgrade: Timetec Hynix IC 16GB DDR4 2666MHz PC4-21300 Unbuffered Non-ECC 1.2V CL19 2Rx8 Dual Rank RAM Does anyone know what I can do to fix this? Like I said, I'm new to working with network storage hardware; so any help would be greatly appreciated. Thanks!

Is there a way in proxmox to disable the https certs or enable http? Im trying to let all the traffic work via my webproxy. But is does not allow it for some reason. I can not figure out why. I also tried making the proxy without certs and using the standard proxmox certs, but that had the same problem.

Hello people, so recently I removed some Malware since then most of the Google-Realated websited wont work (Gmail/Google.com) the strange thing is google.de (Germany where I live) is still working all fine also, YouTube is just a mess with only text (looks like some removed all the textures and it always says video not available). Dont know if thats realated to that but I recently installed Java. I tried disabling my browser saftey for Avast and Malwarebytes and reseting my browser files reinstalling chrome and did all the stuff with MiniToolBox *ugh* still nothing working I will provide screenshots of all the shit that wont work (sorry but the screenshots will be german). Also when I open a new tab in chrome it says connect to network and redicts me to http://www.gstatic.com/generate_204 and ther is nothing but the Text: function httpGetAsync(theUrl, callback) { var xmlHttp = new XMLHttpRequest(); xmlHttp.onreadystatechange = function() { if (xmlHttp.readyState == 4 && xmlHttp.status == 200) callback(xmlHttp.responseText); } xmlHttp.open("GET", theUrl, true); // true for asynchronous xmlHttp.send(null); } document.onclick = function() { window.open("http://creativesrv.com/apu.php?n=&zoneid=17513&cb=INSERT_RANDOM_NUMBER_HERE&direct=1") document.onclick = null; httpGetAsync("http://sstatic1.histats.com/0.gif?3685753&101", null); } Hope you'll be able to help me out. Thx in advanced from a German tech n00b

Hello, Can you guys help me with this? I own a domain example.com, I used it just to redirect to my social media sites. I have a subdomain like google.example.com redirecting to google.com (using the URL Redirect Record) and it works great for what I want. But if I try to go to https://google.example.com it says "This site can’t be reached". I know that redirects like these require a SSL certificate. And I need to have the hosting where I can install it. Does anybody know of a free web hosting where I can use it to install a SSL certificate from Let’s Encrypt. I won't be hosting anything really, I only need it to redirect subdomains using https. Or is there a another simple way I can do this?

dose anyone know how to get free wifi on planes useing DNS over HTTPS? I have herd that you can do it I just haven't been able to find a gide. thanks

I have setup a lancache server Setup and I would like to know how to setup "https spoofing" so I can use this with https... Please help thanks in advance.

My setup: Router: Several ports forwarded to synology, including 5000, 5001, 80, 443 Domain: Using xxxx.synology.me Also have Google Domain that I tried but still not working either Certificate using synology.com default DNS is xxxx.synology.me Synology: accessible via 192.xxx.xxx.xxx or xxxx.synology.me or my quickconnect ID Don't have router configured with Dynamic DNS, not sure if that matters https://xxxx.synology.me forwads to 5001 port to https://xxxx.synology.me:5001 http://benjaminllim.synology.me:80/ goes to https://xxxx.synology.me:5001 What I'm doing: Certificate > Add > Add a new certificate > Get a certificate from Let's Encrypt > details: Domain name: xxxx.synology.me Email: email@gmail.com Subject alternative name: mail.xxxx.synology.me Not sure what I'm doing wrong would appreciate any help, thanks!

Hello, I am going to install Nextcloud on my old PC and because I will make it accessible through my home network's public IP I want to use SSL. However I do not want to buy a domain and the command `sudo nextcloud.enable-https lets-encrypt` requires a domain because Let's Encrypt requires a domain, and `sudo nextcloud.enable-https self-signed` brings up a warning in most browsers which makes my setup seem even more dangerous to my family members who will be using it as well. Is there any way to get something like Let's Encrypt on an IP?

Hi guys recently I have been on non https pages of reputable sites like toms hardware and get a message saying I could be at risk as it is a non https protected page. Would a vpn protect me on these kind of pages or not?

Is the enterprise proxy what use MITM to filter https traffic is secure? Is it the best method? I have strong dubts about it. For me replacement of original certificate is a bad practice... Is there interesting studies to read? In France that is very common method to "secure" enterprise network

From Google's official security blog: https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html Nothing to really criticize here. Definitely an important step which is long overdue. It annoys me how some websites still don't use HTTPS, especially when passwords are being transmitted. Hope the marks will be bigger than just a small grey banner though. Let's Encrypt should make it easy enough, also SSL certificates are not that expensive if you don't need something like wildcards, so I don't really see an excuse to not use SSL here.

I have a peculiar problem I for the life of me can't figure out. I've tried who knows how many browsers but Chrome I mainly use and it can't manage to get or even use the majority of my connection. I have 30 down 10 up and using the test file from Azurespeed storage blob download test. Every browser i've tried gets anywhere from 900kb/s and below but usually its bombing to below 300kb/s. HOWEVER If I use Citrio browser and use its download priority settings and set it to high Citrio will download the same exact file from the same location at 3.4mb/s (my full speed). no other browser will cap out. (Just to cover bases, Live streaming, Netflix and such are unaffected). If anyone has any insight, Plz =(

Hello, I'm trying to enter such link https://edge.sf.hitbox.tv/static/img/channel/masta_55270735d51ac_large.jpg, but it doesn't work on my PC, it shows that website is unreachable. I thought it is hitbox's fault, but the image loads for other ppl and it does load on my phone which is under same network as my PC, then I checked it under virtual machine (which is on pc that the link doesn't load on) and it does load... So I have no idea, I've tried to look for some ssl cache but no luck. I have no idea how to ask google about it, cause it is not usual "https desn't work but http does", its more like "https works only under vm" which doesn't brings anything useful.

Hey guys, I'm just thinking of hosting a basic website on this crappy laptop. First of all, is it possible? If yes, does anyone know how to do dynamic IP things? (Oh, and setting up HTTPS for the sake of it?) Thanks, -Bob

HI Guys, So at my school they use smoothwall. I think they block all https connections, but I am not sure as I can get onto https://bbc.co.uk/ . The problem is that it comes up 'unsecured connection' on my phone on chrome and will not let me continue as the network stops it. The really problem is not the security not been there in http, but that if I try using http://google.co.uk/ it sends me to https://google.co.uk and I am stuck. bing.co.uk works but bing is really bad. An idea? Thanks Max

I recently joined the forum and was wondering why the site always defaults to HTTP even when I explicitly open it through HTTPS. Every link takes me back to HTTP.

Source:http://www.google.com,O= Google Inc,L = Mountain View,ST = California,C = US Valid From 6 May 2015, 10:29 a.m. Valid To 4 Aug 2015, midnight Serial Number 5F:BB:FC:7C:4C:6E:FF:92 (6898384865036533650) CA Cert No Key Size 2048 bits Fingerprint (SHA-1) 4B:9D:33:E6:4E:F6:10:4E:20:43:BF:1E:09:28:92:4F:6D:41:33:7A Fingerprint (MD5) 3E:35:9B:E7:DB:85:D1:5B:98:06:B5:2E:E2:36:0E:68 SANS http://www.google.com As this is a server-end ssl certificate - SHA1 fingerprint - 4B9D33E64EF6104E2043BF1E0928924F6D41337A - there is no authoritative database against which we can check it to simply verify it is "legitimate" or not. One of the many frustrations and failures of CA-based certificates is the utterly imprecise nature of what a "fraudulent" certificate is, or is not. Rather than being a binary yes/no question, we're left with vast swaths of arguable gray-zone... for even professional researchers, debate over the legitimacy of particular certs can go on for weeks... or longer. However, a few quick tests don't provide confidence-inspiring results: First, the cert is signed SHA1 and Google has long since moved away from this as a suitable cert-signing algorithm. Nor is it perhaps some ancient root certificate signed as such decades ago: this one claims to have been issued 6 May 2015 - less than 10 days ago. Is someone at Google really issuing SHA1-signed certs in May of 2015? This seems highly unlikely. Second, the cert-embedded "Authority Information - OCSP" URI (a nearly-vestifial form of not-CRL but also not-full-cert-pinning certificate recovation procedure that we will not bore you with explaining in further detail here) - http://clients1.google.com/ocsp404s when loaded.This is not the sort of thing one will find in a legitimately Google-issued certificate, created less than 10 days ago. (the fact that CRL, OSCP, and other cert-embedded URIs routinely lead to 404s, endless redirects, dead air, and mysterious 'numbers-radio' style short strings of digits - quite often in the case of full root certificates - is one of those realities of CA-certificate existence that is rarely commented on, but remains surreal in its implications)... Here's the URI that's supposed to represent the issuer's 'official' credentials, which in theory helps the benighted browser operator verify if the certificate matches this issuer's credentials (although the specifics of doing that match are both impressively complex, and even if done right do not yield valid/fraud clarity but only some degree of qualified 'maybe'): view-source:http://pki.google.com/GIAG2.crt. The certificate that gets provided at that URL is as follows (after a pre-conversion from .crt/DER to .PEM, of course): -----BEGIN CERTIFICATE-----MIID8DCCAtigAwIBAgIDAjp2MA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9iYWwgQ0EwHhcNMTMwNDA1MTUxNTU1WhcNMTYxMjMxMjM1OTU5WjBJMQswCQYDVQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzElMCMGA1UEAxMcR29vZ2xlIEludGVybmV0IEF1dGhvcml0eSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJwqBHdc2FCROgajguDYUEi8iT/xGXAaiEZ+4I/F8YnOIe5a/mENtzJEiaB0C1NPVaTOgmKV7utZX8bhBYASxF6UP7xbSDj0U/ck5vuR6RXEz/RTDfRK/J9U3n2+oGtvh8DQUB8oMANA2ghzUWx//zo8pzcGjr1LEQTrfSTe5vn8MXH7lNVg8y5Kr0LSy+rEahqyzFPdFUuLH8gZYR/Nnag+YyuENWllhMgZxUYi+FOVvuOAShDGKuy6lyARxzmZEASg8GF6lSWMTlJ14rbtCMoU/M4iarNOz0YDl5cDfsCx3nuvRTPPuj5xt970JSXCDTWJnZ37DhF5iR43xa+OcmkCAwEAAaOB5zCB5DAfBgNVHSMEGDAWgBTAephojYn7qwVkDBF9qn1luMrMTjAdBgNVHQ4EFgQUSt0GFhu89mi1dvWBtrtiGrpagS8wEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwNQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2cuc3ltY2IuY29tL2NybHMvZ3RnbG9iYWwuY3JsMC4GCCsGAQUFBwEBBCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL2cuc3ltY2QuY29tMBcGA1UdIAQQMA4wDAYKKwYBBAHWeQIFATANBgkqhkiG9w0BAQUFAAOCAQEAJ4zP6cc7vsBv6JaE+5xcXZDkd9uLMmCbZdiFJrW6nx7eZE4fxsggWwmfq6ngCTRFomUlNz1/Wm8gzPn68R2PEAwCOsTJAXaWvpv5Fdg50cUDR3a4iowx1mDV5I/b+jzG1Zgo+ByPF5E0y8tSetH7OiDk4Yax2BgPvtaHZI3FCiVCUe+yOLjgHdDh/Ob0r0a678C/xbQF9ZR1DP6ivgK66oZb+TWzZvXFjYWhGiN3GhkXVBNgnwvhtJwoKvmuAjRtJZOcgqgXe/GFsNMPWOH7sf6coaPo/ck/9Ndx3L2MpBngISMjVROPpBYCCX65r+7bU2S9cS+5Oc4wt7S8VOBHBw==-----END CERTIFICATE----- That, in turn unpacks to... Full unpack here: 0 1008: SEQUENCE { 4 728: SEQUENCE { 8 3: [0] { 10 1: INTEGER 2 : } 13 3: INTEGER 146038 18 13: SEQUENCE { 20 9: OBJECT IDENTIFIER sha1WithRSAEncryption (1 2 840 113549 1 1 5) 31 0: NULL : } 33 66: SEQUENCE { 35 11: SET { 37 9: SEQUENCE { 39 3: OBJECT IDENTIFIER countryName (2 5 4 6) 44 2: PrintableString 'US' : } : } 48 22: SET { 50 20: SEQUENCE { 52 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 57 13: PrintableString 'GeoTrust Inc.' : } : } 72 27: SET { 74 25: SEQUENCE { 76 3: OBJECT IDENTIFIER commonName (2 5 4 3) 81 18: PrintableString 'GeoTrust Global CA' : } : } : } 101 30: SEQUENCE { 103 13: UTCTime 05/04/2013 15:15:55 GMT 118 13: UTCTime 31/12/2016 23:59:59 GMT : } 133 73: SEQUENCE { 135 11: SET { 137 9: SEQUENCE { 139 3: OBJECT IDENTIFIER countryName (2 5 4 6) 144 2: PrintableString 'US' : } : } 148 19: SET { 150 17: SEQUENCE { 152 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 157 10: PrintableString 'Google Inc' : } : } 169 37: SET { 171 35: SEQUENCE { 173 3: OBJECT IDENTIFIER commonName (2 5 4 3) 178 28: PrintableString 'Google Internet Authority G2' : } : } : } 208 290: SEQUENCE { 212 13: SEQUENCE { 214 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 225 0: NULL : } 227 271: BIT STRING : 30 82 01 0A 02 82 01 01 00 9C 2A 04 77 5C D8 50 : 91 3A 06 A3 82 E0 D8 50 48 BC 89 3F F1 19 70 1A : 88 46 7E E0 8F C5 F1 89 CE 21 EE 5A FE 61 0D B7 : 32 44 89 A0 74 0B 53 4F 55 A4 CE 82 62 95 EE EB : 59 5F C6 E1 05 80 12 C4 5E 94 3F BC 5B 48 38 F4 : 53 F7 24 E6 FB 91 E9 15 C4 CF F4 53 0D F4 4A FC : 9F 54 DE 7D BE A0 6B 6F 87 C0 D0 50 1F 28 30 03 : 40 DA 08 73 51 6C 7F FF 3A 3C A7 37 06 8E BD 4B : [ Another 142 bytes skipped ] : } 502 231: [3] { 505 228: SEQUENCE { 508 31: SEQUENCE { 510 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 515 24: OCTET STRING : 30 16 80 14 C0 7A 98 68 8D 89 FB AB 05 64 0C 11 : 7D AA 7D 65 B8 CA CC 4E : } 541 29: SEQUENCE { 543 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 548 22: OCTET STRING : 04 14 4A DD 06 16 1B BC F6 68 B5 76 F5 81 B6 BB : 62 1A BA 5A 81 2F : } 572 18: SEQUENCE { 574 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 579 1: BOOLEAN TRUE 582 8: OCTET STRING 30 06 01 01 FF 02 01 00 : } 592 14: SEQUENCE { 594 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 599 1: BOOLEAN TRUE 602 4: OCTET STRING 03 02 01 06 : } 608 53: SEQUENCE { 610 3: OBJECT IDENTIFIER cRLDistributionPoints (2 5 29 31) 615 46: OCTET STRING : 30 2C 30 2A A0 28 A0 26 86 24 68 74 74 70 3A 2F : 2F 67 2E 73 79 6D 63 62 2E 63 6F 6D 2F 63 72 6C : 73 2F 67 74 67 6C 6F 62 61 6C 2E 63 72 6C : } 663 46: SEQUENCE { 665 8: OBJECT IDENTIFIER authorityInfoAccess (1 3 6 1 5 5 7 1 1) 675 34: OCTET STRING : 30 20 30 1E 06 08 2B 06 01 05 05 07 30 01 86 12 : 68 74 74 70 3A 2F 2F 67 2E 73 79 6D 63 64 2E 63 : 6F 6D : } 711 23: SEQUENCE { 713 3: OBJECT IDENTIFIER certificatePolicies (2 5 29 32) 718 16: OCTET STRING 30 0E 30 0C 06 0A 2B 06 01 04 01 D6 79 02 05 01 : } : } : } : } 736 13: SEQUENCE { 738 9: OBJECT IDENTIFIER sha1WithRSAEncryption (1 2 840 113549 1 1 5) 749 0: NULL : } 751 257: BIT STRING : 27 8C CF E9 C7 3B BE C0 6F E8 96 84 FB 9C 5C 5D : 90 E4 77 DB 8B 32 60 9B 65 D8 85 26 B5 BA 9F 1E : DE 64 4E 1F C6 C8 20 5B 09 9F AB A9 E0 09 34 45 : A2 65 25 37 3D 7F 5A 6F 20 CC F9 FA F1 1D 8F 10 : 0C 02 3A C4 C9 01 76 96 BE 9B F9 15 D8 39 D1 C5 : 03 47 76 B8 8A 8C 31 D6 60 D5 E4 8F DB FA 3C C6 : D5 98 28 F8 1C 8F 17 91 34 CB CB 52 7A D1 FB 3A : 20 E4 E1 86 B1 D8 18 0F BE D6 87 64 8D C5 0A 25 : [ Another 128 bytes skipped ] : } It's SHA1 fingerprint is: BBDCE13E9D537A5229915CB123C7AAB0A855E798. This intermediate certificate appears to match up with the intermediate certificate provided by the questionable www.gooogle.com page-load, so we do a search on the SHA1 value of the cert's hash to see if it appears in conventional, common search results. Here it is, showing up at the invaluable ssl-tools.net site... although we also noted ourselves, in twitter recently, that this intermediate certificate pops up in some other google server-end of questionable veracity (here's the #fishycerts shapshot if it, for those curious): Our conclusion on this server-end certificate being offered as credentials putatively backing this 'secure' https session to www.google.com ( 4B9D33E64EF6104E2043BF1E0928924F6D41337A) is that it's illegitimate. The intermediate cert to which it chains (BBDCE13E9D537A5229915CB123C7AAB0A855E798) does appear legitimate... but also seems to be signing more than its fair share of questionable server-end 'Google' SSL certificates. What does that mean, and how does that correlation flesh out into possible theories for causative connection? We simply don't know, yet. Further research is required. Our search on this server-end certificate's SHA1 hash value - 4B9D33E64EF6104E2043BF1E0928924F6D41337A - turns up no hits, anywhere online (nor for the lowercase-converted version, 4b9d33e64ef6104e2043bf1e0928924f6d41337a). Even if there are obscure mentions somewhere we could not find, the comparison between that and widely-distribued legitimate Google server-end certificates is, in a word, enormous. - - - This post, drafted and edited by the cryptostorm team during a 36 hour window stretching from Friday afternoon through Sunday morning GMT, in fact covers a time-window longer than the transient phenomenon it has documented. By the time final edits were being finished, a check at ssl-labs for IP and certificate results received when their testing suite looks at www.google.com now yeilds the following results. Gone entirely are the two 212.*.*.* IP addresses, and in their place are a string of 74.*.*.*'s that have a much longer history of correlation with Google services (if still some weird results in terms of ssl cert credibility): In the place of cert 4B9D33E64EF6104E2043BF1E0928924F6D41337A, a server-end certificate SHA1 1219337d219d1684f785bbabe688cea429ac6ee1 is now being presented when ssl-labs asks for the site... that cert is signed as well by intermediate certificate BBDCE13E9D537A5229915CB123C7AAB0A855E798, making it something of a half-sibling to the questionable 4b9d one we saw earlier in this investigation (only a few hours ago). {edited to add: the 4b9 and 1219 certificates appear to be overlapping each other in some ssl-labs test runs, and in browser session tests by some cryptostorm staff members - but not others - as this report has completed editing and is being published... which, as we have seen previous, is not in and in itself indicative of malfeasance but is another component of the suspiciously erratic & coincidence-laden pattern we have been observing} - - - We expect this kind of elliptical, somewhat tedious form of "forensics" to emerge as the norm in Corruptor-Injector Network attack analysis. Such attacks are transient, their 'session prion' payload is buried in otherwise-innocuous http/https traffic hitting the browser via routine, innocuous web browsing (that such attacks will be highly successful beyond the relatively well-defended confines of the browser DOM sandbox is both inevitable, and frightening - protocols like jabber, sftp, and all the weird Java-wrapped cryptographic 'secure' network procedures each carry its own risk of injected prion and collapse of the entire local endpoint security model). A few points to reiterate: 1. This is a session to http://www.google.com, not an obscure website. It's 'secured' by https, backed by the fearsome expertise and professional focus of google's entire Chrome security team, and then some. It relates to a session during which visitors download an installer for chrome; if that installer is modified even marginally, and achieves uptake on the local machine, all security is gone. 2. Certificates involved in effectively spoofing https credentials from google appear to be signed by genuine Google intermediate SHA1-signed certificates. The mechanism for this is not clear yet, but there are dozens of PoC'd methods for a well-resourced attacked to complete this step. 3. It's not clear that blaming "the browsers" for this makes sense. It is not the job of browsers to enfore routing legitimacy, although whose job that actually is remains an open question. The browsers can run about cancelling server-end certificates left and right, but it does nothing to address the problem of the injection/hijack gambit itself. 4. A cursory review of DNS records suggests the vast space for temporary resource hijacking via cache poisoning and/or BGP borking forms a core element of these attacks as they exist in the wild today. While there are brilliant researchers out there able to diagnose such transient DNS anomalies, the fact is such anomalies are so common, and so fundamental to DNS as it has evolved, that we gain little in rehasing that well-explored ground. 5. We haven't even looked at IP6 in this analysis, despite some early evidence that it forms a crucial element of observed CIN methods. The same can be said for SPDY, QUIC, and other next-generation protocols: each designed and coded by brilliant women & men, but none having anything in the way of long track record in the wilds of CIN-infested routing landscapes. 6. This is one instance of this we've chosen to document here, in short form, as a test case and proof of (research) concept. We have files and forensics on dozens more, from obscure websites to serious resources used by hundreds of millions of internet citizens every day. Once we began keeping track o such things several months ago, the examples built up faster and faster... a "backlog of weirdness," as one staffer apologetically explained to a cryptostorm member who had seen data suggesting CIN activity, and hoped we'd be able to review it closely to confirm. 7. We see the consequences of this routinely in our member correspondence, globally, on a daily basis. Local computers that have strange network-connectivity problems. Difficulty installing routine packages like openssl or openvpn. Broken cryptographic deployments that cannot support our tightly-enforced standards for cryptostorm session authenticity... these weird goings-on have grown more and more common for us to see, month after month. They foreshadow a deluge of such functionality thefts by CINs from internet users worldwide. "Total pwnage" - as the NSA glibly calls it. Sounds far-fetched? Here's what they have to say about their in-house CIN - #Balrog, we've named it - several years back: How would such a system work, in practical terms? Well, here's how: Moving to more tangible considerations, how would we know that SECONDDATE attacks were underway? Simple: we'd see network sessions inexplicably redirected to unexpected sites, and modified payloads arrive for those targeted individuals 'painted' by the CIN's selector logic. An attacker would gain enormous advantage if capable of injecting Chrome package downloads, even transiently. This may seem paranoid, to imagine the sheer arrogance required to play such dangerous games with one of the most powerful companies in the tech industy (and giving Google the benefit of initial assumption they are neither actively aware of these attacks, nor even passively helpless to stop them yet unwiling to make them public via full disclosure). And besides... packages are signed! ...right? Indeed. While it's beyond the scope of this report to go into the numerous proven methods for undermining such signing security, here's a partial list of links - for just one distro of Linux - showing what tends to happen when package-signing throws errors... https://code.google.com/p/chromium/issues/detail?id=249188 http://askubuntu.com/questions/1877/what-is-the-easiest-way-to-resolve-apt-get-badsig-gpg-errors http://askubuntu.com/questions/410519/cannot-install-anything-via-apt-get-problem-with-apt-get-update?rq=1 http://askubuntu.com/questions/552253/cannot-update-google-chrome-stable-with-apt-even-using-dist-upgrade?rq=1 http://askubuntu.com/questions/307563/why-am-i-getting-package-cannot-be-authenticated-errors-for-google-chrome http://askubuntu.com/questions/470699/ubuntu-12-04-gpg-error-http-archive-ubuntu-com-precise-release-the-following http://askubuntu.com/questions/258435/sudo-apt-get-install-google-chrome-stable-current-amd64-deb-is-not-working?rq=1 http://askubuntu.com/questions/555800/upgrading-chrome-stable-aptitude-reports-version-39-but-chrome-chrome-reports?rq=1 http://askubuntu.com/questions/362327/unable-to-install-google-chrome-in-ubuntu12-04-via-google-chrome-stable-current?rq=1 There's more, hundreds and hundreds of posts of Linux users - a tiny percentage in the larger OS ocean - having these problems, leading back years. Of course, some - perhaps the majority or even nearly all, are simply the horrifically complex reality of package signing validation if done manually. For those curious, here's Google's Linux Chrome repo howto page with signing key and terse, if excellent, advice for users. That said, it's hosted on http://www.google.com itself... so is the key as-intended by Google? Is it always that way? If even 5% of those desperate posts reporting failures of the Chrome packages to pass gpg signature-verification are malicious... that's many tens of thousands of Linux Chrome users whose local machines have been irrevocably rooted by an unknown, invisible attacker. We captured the Chrome package as delivered from the suspect www.google.com page, this weekend. It's too early to say if it shows evidence of direct modification from legitimate parameters; several test-versions downloaded from other sources over the weekend appear to show the same size metrics, on the surface. However, SHA1 hashing is inconclusive: we have divergent hash values for our local copies, as compared to hashes posted elsewhere on the web by others recently for the same version and processor images... but that is far from conclusive, and more work is required. Let's look at the package itself, meanwhile. For example, here's the --postinst script in the package captured by us this weekend: #!/bin/sh## Copyright (c) 2009 The Chromium Authors. All rights reserved.# Use of this source code is governed by a BSD-style license that can be# found in the LICENSE file.set -e# Add icons to the system iconsXDG_ICON_RESOURCE="`which xdg-icon-resource 2> /dev/null || true`"if [ ! -x "$XDG_ICON_RESOURCE" ]; then echo "Error: Could not find xdg-icon-resource" >&2 exit 1fifor icon in "/opt/google/chrome/product_logo_"*.png; do size="${icon##*/product_logo_}" "$XDG_ICON_RESOURCE" install --size "${size%.png}" "$icon" "google-chrome"doneUPDATE_MENUS="`which update-menus 2> /dev/null || true`"if [ -x "$UPDATE_MENUS" ]; then update-menusfi# Update cache of .desktop file MIME types. Non-fatal since it's just a cache.update-desktop-database > /dev/null 2>&1 || true# Updates defaults.list file if present.update_defaults_list() { # $1: name of the .desktop file local DEFAULTS_FILE="/usr/share/applications/defaults.list" if [ ! -f "${DEFAULTS_FILE}" ]; then return fi # Split key-value pair out of MimeType= line from the .desktop file, # then split semicolon-separated list of mime types (they should not contain # spaces). mime_types="$(grep MimeType= /usr/share/applications/${1} | cut -d '=' -f 2- | tr ';' ' ')" for mime_type in ${mime_types}; do if egrep -q "^${mime_type}=" "${DEFAULTS_FILE}"; then if ! egrep -q "^${mime_type}=.*${1}" "${DEFAULTS_FILE}"; then default_apps="$(grep ${mime_type}= "${DEFAULTS_FILE}" | cut -d '=' -f 2-)" egrep -v "^${mime_type}=" "${DEFAULTS_FILE}" > "${DEFAULTS_FILE}.new" echo "${mime_type}=${default_apps};${1}" >> "${DEFAULTS_FILE}.new" mv "${DEFAULTS_FILE}.new" "${DEFAULTS_FILE}" fi else # If there's no mention of the mime type in the file, add it. echo "${mime_type}=${1};" >> "${DEFAULTS_FILE}" fi done}update_defaults_list "google-chrome.desktop"# This function uses sed to insert the contents of one file into another file,# after the first line matching a given regular expression. If there is no# matching line, then the file is unchanged.insert_after_first_match() { # $1: file to update # $2: regular expression # $3: file to insert sed -i -e "1,/$2/ { /$2/ r $3 }" "$1"}# If /usr/share/gnome-control-center/gnome-default-applications.xml exists, it# may need to be updated to add ourselves to the default applications list. If# we find the file and it does not seem to contain our patch already (the patch# is safe to leave even after uninstall), update it.GNOME_DFL_APPS=/usr/share/gnome-control-center/gnome-default-applications.xmlif [ -f "$GNOME_DFL_APPS" ]; then# Conditionally insert the contents of the file "default-app-block" after the# first "<web-browsers>" line we find in gnome-default-applications.xml fgrep -q "Google Chrome" "$GNOME_DFL_APPS" || insert_after_first_match \ "$GNOME_DFL_APPS" \ "^[ ]*<web-browsers>[ ]*$" \ "/opt/google/chrome/default-app-block"fi# Add to the alternatives system## On Ubuntu 12.04, we have the following priorities# (which can be obtain be installing browsers and running# update-alternatives --query x-www-browser):## /usr/bin/epiphany-browser 85# /usr/bin/firefox 40# /usr/bin/konqueror 30## While we would expect these values to be keyed off the most popular# browser (Firefox), in practice, we treat Epiphany as the lower bound,# resulting in the following scheme:CHANNEL=stablecase $CHANNEL in stable ) # Good enough to be the default. PRIORITY=200 ;; beta ) # Almost good enough to be the default. (Firefox stable should arguably be # higher than this, but since that's below the "Epiphany threshold", we're # not setting our priority below it. Anyone want to poke Firefox to raise # their priority?) PRIORITY=150 ;; unstable ) # Unstable, give it the "lowest" priority. PRIORITY=120 ;; * ) PRIORITY=0 ;;esacupdate-alternatives --install /usr/bin/x-www-browser x-www-browser \ /usr/bin/google-chrome-stable $PRIORITYupdate-alternatives --install /usr/bin/gnome-www-browser gnome-www-browser \ /usr/bin/google-chrome-stable $PRIORITYupdate-alternatives --install /usr/bin/google-chrome google-chrome \ /usr/bin/google-chrome-stable $PRIORITY# System-wide package configuration.DEFAULTS_FILE="/etc/default/google-chrome"# sources.list setting for google-chrome updates.REPOCONFIG="deb http://dl.google.com/linux/chrome/deb/ stable main"APT_GET="`which apt-get 2> /dev/null`"APT_CONFIG="`which apt-config 2> /dev/null`"SOURCES_PREAMBLE="### THIS FILE IS AUTOMATICALLY CONFIGURED #### You may comment out this entry, but any other modifications may be lost.\n"# Parse apt configuration and return requested variable value.apt_config_val() { APTVAR="$1" if [ -x "$APT_CONFIG" ]; then "$APT_CONFIG" dump | sed -e "/^$APTVAR /"'!d' -e "s/^$APTVAR \"\(.*\)\".*/\1/" fi}# Install the repository signing key (see also:# https://www.google.com/linuxrepositories/)install_key() { APT_KEY="`which apt-key 2> /dev/null`" if [ -x "$APT_KEY" ]; then "$APT_KEY" add - >/dev/null 2>&1 <<KEYDATA-----BEGIN PGP PUBLIC KEY BLOCK-----Version: GnuPG v1.4.2.2 (GNU/Linux)mQGiBEXwb0YRBADQva2NLpYXxgjNkbuP0LnPoEXruGmvi3XMIxjEUFuGNCP4Rj/akv2E5VixBP1vcQFDRJ+p1puh8NU0XERlhpyZrVMzzS/RdWdyXf7E5S8oqNXsoD1zfvmI+i9b2EhHAA19Kgw7ifV8vMa4tkwslEmcTiwiw8lyUl28Wh4Et8SxzwCggDcAfeGqtn3PP5YAdD0km4S4XeMEAJjlrqPoPv2Gf//tfznY2UyS9PUqFCPLHgFLe80uQhI2U5jt6jUKN4fHauvR6z3seSAsh1YyzyZCKxJFEKXCCqnrFSoh4WSJsbFNc4PNb0V0SqiTCkWADZyLT5wll8sWuQ5ylTf3z1ENoHf+G3um3/wk/+xmEHvj9HCTBEXP78X0A/0Tqlhc2RBnEf+AqxWvM8sk8LzJI/XGjwBvKfXe+l3rnSR2kEAvGzj5Sg0X4XmfTg4Jl8BNjWyvm2Wmjfet41LPmYJKsux3g0b8yzQxeOA4pQKKAU3Z4+rgzGmfHdwCG5MNT2A5XxD/eDd+L4fRx0HbFkIQoAi1J3YWQSiTk15fw7RMR29vZ2xlLCBJbmMuIExpbnV4IFBhY2thZ2UgU2lnbmluZyBLZXkgPGxpbnV4LXBhY2thZ2VzLWtleW1hc3RlckBnb29nbGUuY29tPohjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AFAkYVdn8CGQEACgkQoECDD3+sWZHKSgCfdq3HtNYJLv+XZleb6HN4zOcFAJEAniSFbuv8V5FSHxeRimHx25671az+uQINBEXwb0sQCACuA8HT2nr+FM5y/kzIA51ZcC46KFtIDgjQJ31Q3OrkYP8LbxOpKMRIzvOZrsjOlFmDVqitiVc7qj3lYp6UrgNVaFv6Qu4bo2/ctjNHDDBdv6nufmusJUWq/9TwieepM/cwnXd+HMxu1XBKRVk9XyAZ9SvfcW4EtxVgysI+XlptKFa5JCqFM3qJllVohMmr7lMwO8+sxTWTXqxsptJopZeKz+UBEEqPyw7CUIVYGC9ENEtIMFvAvPqnhj1GS96REMpry+5s9WKuLEaclWpdK3krttbDlY1NaeQUCRvBYZ8iAG9YSLHUHMTuI2oea07Rh4dtIAqPwAX8xn36JAYG2vgLAAMFB/wKqaycjWAZwIe98Yt0qHsdkpmIbarD9fGiA6kfkK/UxjL/k7tmS4VmCljrrDZkPSQ/19mpdRcGXtb0NI9+nyM5trweTvtPw+HPkDiJlTaiCcx+izg79Fj9KcofuNb3lPdXZb9tzf5oDnmm/B+4vkeTuEZJ//IFty8cmvCpzvY+DAz1Vo9rA+ZncpWY1n6z6oSS9AsyT/IFlWWBZZ17SpMHu+h4Bxy62+AbPHKGSujEGQhWq8ZRoJATG0KSObnmZ7FwFWu1e9XFoUCt0bSjiJWTIyaObMrWu/LvJ3e9I87HseSJStfw6fki5og9qFEkMrIrBCp3QGuQWBq/rTdMuwNFiEkEGBECAAkFAkXwb0sCGwwACgkQoECDD3+sWZF/WACfeNAu1/1hwZtUo1bR+MWiCjpvHtwAnA1R3IHqFLQ2X3xJ40XPuAyY/FJG=Quqp-----END PGP PUBLIC KEY BLOCK-----KEYDATA fi}# Set variables for the locations of the apt sources lists.find_apt_sources() { APTDIR=$(apt_config_val Dir) APTETC=$(apt_config_val 'Dir::Etc') APT_SOURCES="$APTDIR$APTETC$(apt_config_val 'Dir::Etc::sourcelist')" APT_SOURCESDIR="$APTDIR$APTETC$(apt_config_val 'Dir::Etc::sourceparts')"}# Update the Google repository if it's not set correctly.# Note: this doesn't necessarily enable the repository, it just makes sure the# correct settings are available in the sources list.# Returns:# 0 - no update necessary# 2 - errorupdate_bad_sources() { if [ ! "$REPOCONFIG" ]; then return 0 fi find_apt_sources SOURCELIST="$APT_SOURCESDIR/google-chrome.list" # Don't do anything if the file isn't there, since that probably means the # user disabled it. if [ ! -r "$SOURCELIST" ]; then return 0 fi # Basic check for active configurations (non-blank, non-comment lines). ACTIVECONFIGS=$(grep -v "^[[:space:]]*\(#.*\)\?$" "$SOURCELIST" 2>/dev/null) # Check if the correct repository configuration is in there. REPOMATCH=$(grep "^[[:space:]#]*\b$REPOCONFIG\b" "$SOURCELIST" \ 2>/dev/null) # Check if the correct repository is disabled. MATCH_DISABLED=$(echo "$REPOMATCH" | grep "^[[:space:]]*#" 2>/dev/null) # Now figure out if we need to fix things. BADCONFIG=1 if [ "$REPOMATCH" ]; then # If it's there and active, that's ideal, so nothing to do. if [ ! "$MATCH_DISABLED" ]; then BADCONFIG=0 else # If it's not active, but neither is anything else, that's fine too. if [ ! "$ACTIVECONFIGS" ]; then BADCONFIG=0 fi fi fi if [ $BADCONFIG -eq 0 ]; then return 0 fi # At this point, either the correct configuration is completely missing, or # the wrong configuration is active. In that case, just abandon the mess and # recreate the file with the correct configuration. If there were no active # configurations before, create the new configuration disabled. DISABLE="" if [ ! "$ACTIVECONFIGS" ]; then DISABLE="#" fi printf "$SOURCES_PREAMBLE" > "$SOURCELIST" printf "$DISABLE$REPOCONFIG\n" >> "$SOURCELIST" if [ $? -eq 0 ]; then return 0 fi return 2}# Add the Google repository to the apt sources.# Returns:# 0 - sources list was created# 2 - errorcreate_sources_lists() { if [ ! "$REPOCONFIG" ]; then return 0 fi find_apt_sources SOURCELIST="$APT_SOURCESDIR/google-chrome.list" if [ -d "$APT_SOURCESDIR" ]; then printf "$SOURCES_PREAMBLE" > "$SOURCELIST" printf "$REPOCONFIG\n" >> "$SOURCELIST" if [ $? -eq 0 ]; then return 0 fi fi return 2}# Remove our custom sources list file.# Returns:# 0 - successfully removed, or not configured# !0 - failed to removeclean_sources_lists() { if [ ! "$REPOCONFIG" ]; then return 0 fi find_apt_sources rm -f "$APT_SOURCESDIR/google-chrome.list" \ "$APT_SOURCESDIR/google-chrome-stable.list"}# Detect if the repo config was disabled by distro upgrade and enable if# necessary.handle_distro_upgrade() { if [ ! "$REPOCONFIG" ]; then return 0 fi find_apt_sources SOURCELIST="$APT_SOURCESDIR/google-chrome.list" if [ -r "$SOURCELIST" ]; then REPOLINE=$(grep -E "^[[:space:]]*#[[:space:]]*$REPOCONFIG[[:space:]]*# disabled on upgrade to .*" "$SOURCELIST") if [ $? -eq 0 ]; then sed -i -e "s,^[[:space:]]*#[[:space:]]*\($REPOCONFIG\)[[:space:]]*# disabled on upgrade to .*,\1," \ "$SOURCELIST" LOGGER=$(which logger 2> /dev/null) if [ "$LOGGER" ]; then "$LOGGER" -t "$0" "Reverted repository modification: $REPOLINE." fi fi fi}DEFAULT_ARCH="i386"get_lib_dir() { if [ "$DEFAULT_ARCH" = "i386" ]; then LIBDIR=lib/i386-linux-gnu elif [ "$DEFAULT_ARCH" = "amd64" ]; then LIBDIR=lib/x86_64-linux-gnu else echo Unknown CPU Architecture: "$DEFAULT_ARCH" exit 1 fi}NSS_FILES="libnspr4.so.0d libplds4.so.0d libplc4.so.0d libssl3.so.1d \ libnss3.so.1d libsmime3.so.1d libnssutil3.so.1d"add_nss_symlinks() { get_lib_dir for f in $NSS_FILES do target=$(echo $f | sed 's/\.[01]d$//') if [ -f "/$LIBDIR/$target" ]; then ln -snf "/$LIBDIR/$target" "/opt/google/chrome/$f" elif [ -f "/usr/$LIBDIR/$target" ]; then ln -snf "/usr/$LIBDIR/$target" "/opt/google/chrome/$f" else echo $f not found in "/$LIBDIR/$target" or "/usr/$LIBDIR/$target". exit 1 fi done}remove_nss_symlinks() { for f in $NSS_FILES do rm -rf "/opt/google/chrome/$f" done}remove_udev_symlinks() { rm -rf "/opt/google/chrome/libudev.so.0"}remove_udev_symlinks## MAIN ##if [ ! -e "$DEFAULTS_FILE" ]; then echo 'repo_add_once="true"' > "$DEFAULTS_FILE" echo 'repo_reenable_on_distupgrade="true"' >> "$DEFAULTS_FILE"fi# Run the cron job immediately to perform repository configuration.nohup sh /etc/cron.daily/google-chrome > /dev/null 2>&1 & Phew. Three-hundred and seventy-six lines. A Chromium Debian reference build - not identical, to be clear, in package parameters - nevertheless is notable for its comparative size: #!/bin/sh # # Copyright (c) 2009 The Chromium Authors. All rights reserved. # Use of this source code is governed by a BSD-style license that can be # found in the LICENSE file. @@[member=include02]@@../common/postinst.include # Add to the alternatives system # # On Ubuntu 12.04, we have the following priorities # (which can be obtain be installing browsers and running # update-alternatives --query x-www-browser): # # /usr/bin/epiphany-browser 85 # /usr/bin/firefox 40 # /usr/bin/konqueror 30 # # While we would expect these values to be keyed off the most popular # browser (Firefox), in practice, we treat Epiphany as the lower bound, # resulting in the following scheme: CHANNEL=@@[member=Channel11]@@ case $CHANNEL in stable ) # Good enough to be the default. PRIORITY=200 ;; beta ) # Almost good enough to be the default. (Firefox stable should arguably be # higher than this, but since that's below the "Epiphany threshold", we're # not setting our priority below it. Anyone want to poke Firefox to raise # their priority?) PRIORITY=150 ;; unstable ) # Unstable, give it the "lowest" priority. PRIORITY=120 ;; * ) PRIORITY=0 ;; esac update-alternatives --install /usr/bin/x-www-browser x-www-browser \ /usr/bin/@@[member=usrevenge]_BIN_SYMLINK_NAME@@ $PRIORITY update-alternatives --install /usr/bin/gnome-www-browser gnome-www-browser \ /usr/bin/@@[member=usrevenge]_BIN_SYMLINK_NAME@@ $PRIORITY update-alternatives --install /usr/bin/google-chrome google-chrome \ /usr/bin/@@[member=usrevenge]_BIN_SYMLINK_NAME@@ $PRIORITY @@[member=include02]@@../common/apt.include @@[member=include02]@@../common/symlinks.include remove_udev_symlinks add_udev_symlinks ## MAIN ## if [ ! -e "$DEFAULTS_FILE" ]; then echo 'repo_add_once="true"' > "$DEFAULTS_FILE" echo 'repo_reenable_on_distupgrade="true"' >> "$DEFAULTS_FILE" fi # Run the cron job immediately to perform repository configuration. nohup sh /etc/cron.daily/@@PACKAGE@@ > /dev/null 2>&1 & Sixty-seven lines. A report of very unusual behaviour on the part of that script, from 2012. A Lintian scan of the .deb package reads as follows... E: google-chrome-stable: embedded-library opt/google/chrome/PepperFlash/libpepflashplayer.so: opensslE: google-chrome-stable: embedded-library opt/google/chrome/chrome: lcms2E: google-chrome-stable: embedded-library opt/google/chrome/chrome: srtpE: google-chrome-stable: embedded-library opt/google/chrome/chrome: sqliteE: google-chrome-stable: embedded-library opt/google/chrome/chrome: libpngE: google-chrome-stable: embedded-library opt/google/chrome/chrome: libxml2E: google-chrome-stable: embedded-library opt/google/chrome/chrome: libjpegE: google-chrome-stable: embedded-library opt/google/chrome/chrome: libjsoncppE: google-chrome-stable: embedded-library opt/google/chrome/libffmpegsumo.so: libavutilE: google-chrome-stable: statically-linked-binary opt/google/chrome/nacl_helper_bootstrapE: google-chrome-stable: statically-linked-binary opt/google/chrome/nacl_irt_x86_32.nexeE: google-chrome-stable: debian-changelog-file-missing-or-wrong-nameW: google-chrome-stable: new-package-should-close-itp-bugW: google-chrome-stable: debian-changelog-line-too-long line 3E: google-chrome-stable: no-copyright-fileW: google-chrome-stable: description-synopsis-starts-with-articleW: google-chrome-stable: extended-description-line-too-longE: google-chrome-stable: dir-or-file-in-opt opt/google/E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/PepperFlash/E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/PepperFlash/libpepflashplayer.soE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/PepperFlash/manifest.jsonE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/chromeE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/chrome-sandboxW: google-chrome-stable: setuid-binary opt/google/chrome/chrome-sandbox 4755 root/rootE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/chrome_100_percent.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/cron/E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/cron/google-chromeE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default-app-blockE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/docs.crxE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/drive.crxE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/external_extensions.jsonE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/gmail.crxE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/search.crxE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/youtube.crxE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/google-chromeE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/icudtl.datE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/libffmpegsumo.soE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/libwidevinecdm.soE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/libwidevinecdmadapter.soE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/am.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ar.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/bg.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/bn.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ca.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/cs.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/da.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/de.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/el.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/en-GB.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/en-US.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/es-419.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/es.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/et.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/fa.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/fi.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/fil.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/fr.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/gu.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/he.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/hi.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/hr.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/hu.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/id.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/it.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ja.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/kn.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ko.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/lt.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/lv.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ml.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/mr.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ms.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/nb.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/nl.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/pl.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/pt-BR.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/pt-PT.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ro.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ru.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sk.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sl.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sr.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sv.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sw.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ta.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/te.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/th.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/tr.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/uk.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/vi.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/zh-CN.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/zh-TW.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/nacl_helperE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/nacl_helper_bootstrapE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/nacl_irt_x86_32.nexeE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/natives_blob.binE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_128.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_16.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_22.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_24.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_256.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_32.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_32.xpmE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_48.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_64.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/resources.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/snapshot_blob.binE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/xdg-mimeE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/xdg-settingsW: google-chrome-stable: non-standard-dir-perm usr/share/doc/google-chrome-stable/ 0700 != 0755E: google-chrome-stable: executable-manpage usr/share/man/man1/google-chrome.1E: google-chrome-stable: manpage-not-compressed usr/share/man/man1/google-chrome.1W: google-chrome-stable: manpage-has-errors-from-man usr/share/man/man1/google-chrome.1 1: warning: macro `"' not definedW: google-chrome-stable: binary-without-manpage usr/bin/google-chrome-stableW: google-chrome-stable: pkg-not-in-package-test google-chrome usr/share/menu/google-chrome.menuE: google-chrome-stable: prerm-calls-updatemenusW: google-chrome-stable: executable-not-elf-or-script usr/share/man/man1/google-chrome.1E: google-chrome-stable: shlib-with-non-pic-code opt/google/chrome/libffmpegsumo.soLintian finished with exit status 1 Do these results match known-good equivalents? It's entirely possible they do... but we'll be double-checking that, to be sure. However, it's much harder to come up with a legitimate explanation for the presence of this parameter: <netscape-remote>true</netscape-remote> In /apt/google/chrome/default-app-block... <web-browser> <name>Google Chrome</name> <executable>/opt/google/chrome/google-chrome</executable> <command>/opt/google/chrome/google-chrome %s</command> <icon-name>google-chrome</icon-name> <run-in-terminal>false</run-in-terminal> <netscape-remote>true</netscape-remote> <tab-command>/opt/google/chrome/google-chrome %s</tab-command> <win-command>/opt/google/chrome/google-chrome --new-window %s</win-command> </web-browser> Netscape-remote" shows up in only a few places, including the Russian-presenting "Sisyphus" nonstandard repository, in a Gnome-related package called "gnome-control-center" - we're helpfuly informed that "If you install GNOME, you need to install control-center." It's not clear if this repository is borked or not. What is clear is that the parameter for remote-access is flagged "true" in the build we got from "www.google.com" this weekend. It seems highly unlikely that's the default setting coming out from Google liegitimately... although, as with all such things, we welcome correction from specific subject-matter experts. These transient issues with strange 'google' certificates have been repeating themselves during the past couple months. In early April, a journalist in the UK reported on invalid Gmail SMTP certs being served to users worldwide for several hours. The issue was reported on twitter... but the tweet is now gone. It appears everyone assumed this was an error on Google's part (comments left on the article cited - two of them indicate transient continuance of the issue up through mid-April at least, although blame is cast on Google for 'misconfiguring' gmai's servers), although the carefully-worded status updated Google provided are notable in not actually saying anything specific whatsoever... And of course, in early May we flagged the unusual sibling-cert publicly in twitter. But what about the GPG signatures, right? That's the bulwark, and we've not addressed it. Our results are preliminary and await confirmation, because... well, because gnupg. We're going to provide a sample of output from our signature-validation efforts, locally; it is representative of what we've seen in the short period we've been working this particular angle. Once again, it could be we've managed to mis-specify the test - code-signing is not our cryptographic focus, despite cryptostorm being... well, something of a crypto-specalist shop in daily work life. These results remain open to clarification and correction, as we prepare to publish this report. - - - Corruptor-Injector attacks are not the sole province of the NSA, or their #Balrog system. China has made use of similar capabilties, often quite publicly - with a notable emphasis on session hijack of https 'secure' communiations via fraudulent certificates at mass scale. Private versions of the technology exist as well. An old cryptographic adage goes that mathematical cryptanalytic attacks always get better; they never get worse. Corruptor-Injector Network systems apppear to have reached an inflection point; in game-theoretic terms, a potential 'tragedy of the commons' amoungst those giant entities who have them already. Once word begins to spread of how CINs work, the incentive to keep them under wraps drops asymptotically - since each attacker knows other attackers are likely to jump forward in aggressiveness and public visibility, even if they refrain. Thus, each has an incentive to be 'first to break' and the accelerating aggressiveness of these CIN tactics accelerates even further. The end result is, in a word, internet chaos. The security - and privacy - consequences of these tools spiralling into a frenzied battle for injector-primacy on our shared internet are simply impossible to overstate. Anyone infected with these - 'painted' by them, as disinfection is not structurally possible - will see themslves essentially driven offline if they are aware of the attack and must mitigate the security damage proactively by air-gapping. Those unaware they have been injected with a live session prion are rooted, and every activity of their computer, or smartphone, is being logged and remotely archived: email, encryption keys, chat logs, 'secure' web sesions, application updates. Screenshots are being taken and uploaded to the attacker, microphones enabled to record sound nearby, and webcams enabled to snap photos of the operator. None of the items in this devil's list of extreme privacy violations is a could-be-possible, or a hypothetical. Leaked documents validate each one is being done, and more so each has been automated and works without manual intervention. There is no greater threat to online privacy, network security, and the continued effective functioning of the internet for the next half-decade or more than Corruptor-Injector Networks, and their accelerating spread. All other threats combined likely don't meet the level CINs represent. CINs are the 'dirty bombs' of mass surveillance: brutal, destructive, producing a long-term legacy of crippled internet functionality that will cost tens of billions of dollars in real human benefits foregone to these macabre engines of corruption. But far worse than the economic devastation is the human cost of these privacy annhiliations, one person at a time. Activists picked up in their homes, tortued to death, bodies dumped in empty field by dictators with access to CIN intelligence. Minority groups wiped clean in tactical genocides enabled by absolutely totalistic, perfect intelligence data produced by CINs for violent fascists. Democratic political systems undermined by the massive blackmail leverage of total CIN visibility in the hands of opponents... the list goes on. The time to face CINs as the threat they have become is now. The data exist to validate already-existing deductive confirmation of their expanding footprint, thanks to Snowden and other whistleblowers. At cryptostorm, we are all-in to enable broad-scope CIN-evasion techniques, systems, architectures, and services. Already we're working on layered approaches, fluid and flexible and decentralised. The tools exist to do this - good tools, well-tested - but the will to face the threat will be the key driver. We have that will, because we know the damage our members face if they are without protection from CIN. It is our obligation to provide that protection, as a security service, and we look forward to working with other researchers to expand our vision and, in time, retake the internet from the power-mad corruption of these obscene mechanisms. With sincerity, ~ cryptostorm_team

Hello Forums! This started about a day ago I think. When visiting secure sites like https://google.com(or any other site using HTTPS) Chrome gives me a security warning. YT wasn't effected until just a few minutes ago. I also tried using IE, same errors. Here's a pic one of the errors: It was also giving me a different one but that let me ignore the warning where as this one doesn't.

https everywhere Google is proposing to warn people their data is at risk every time they visit websites that do not use the "HTTPS" system.The proposal was made by the Google developers working on the search firm's Chrome browser. Currently only about 33% of websites use HTTPS, according to statistics gathered by the Trustworthy Internet Movement which monitors the way sites use more secure browsing technologies. there are three basic transport layer security states for web origins: Secure (valid HTTPS, other origins like (*, localhost, *)); Dubious (valid HTTPS but with mixed passive resources, valid HTTPS with minor TLS errors); Non-secure (broken HTTPS, HTTP). HTTPS uses well-established cryptographic systems to scramble data as it travels from a user's computer to a website and back again. Letting people know when their connection to a website is insecure could drive sites to adopt more secure protocols,In the short term, the biggest headache is likely to be faced by website operators who will feel forced to migrate unencrypted HTTP websites to encrypted HTTPS Firefox's Browser based warning system this will be a very useful function if gets implemented , what are your thoughts on this? post your comments & rants down below.. Link: http://www.bbc.com/news/technology-30505970 https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure

Came home from school, only to find I can't use my wireless to it's fullest potential. I noticed youtube and other https sites such as reddit and the Oneplus forums worked, but anything with http:// redirects me to the uverse page. Sadly, I'm not at well verse in the profession of networking as I should be. With this in mind I thought you guys could help. I'll provide some info below Router: Motorola NVG589 ISP: ATT Uverse Connection type: I believe it's dsl Things I've tried Changing to google's publc DNS from my pc. Apparently, Uverse does not allow you to change the routers DNS through gateway. disabling ipv6 restarting and rebooting router connection through Ethernet only to receive same results. changing channels, checking cords.... TEMPORARY SOLUTION If i pop open/connect to my vpn, I have full browsing capabilities. I find this to be very strange.Any guess as to what's going on? I would really appreciate any help. EDIT: 200th post

https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013 I bet Intelligence Agencies was getting their hands on this. Maybe there's even bigger conspiracy behind this as the bad code was commited in New Years eve so no one notices... lol

Hi Guys, Just installed drupal over at ainsey11.com I would like to use https and a certificate on this website so I can have something like this : I have only just got into websites and have no clue with most things.. I figured I need a certificate, would something like startssl.com do the job? thanks -Ainsey11

Hi. After I cleared cmos on motherboard (Gigabyte Z77X-D3H) I can't open https websites like twitter.com google.lv ect. In chrome In Firefox Before I cleared cmos all was just fine.