Request for Comments: Root Certificate Trends

every program, every driver, and every website now causes get-requests to a dwingling list of certificate stores and trusts. the trust model was tolerated for the longest time, because it just didn't affect core productivity -- you could, and did, route around it. or manage updates yourself. but over time, this has created an enourmously failed design to expand to a full-fabric dependency (design = the insistence on SSL/TLS -and- trust/PKI paired together, licensed, and sold for failed businesses to make money). insert heartbleed, insert iran/cia-fbi/romania/china cert hijacking, insert accelerating massive-surface attack vector: break in once, break in jewtel-wide. this prompted a variety of changes in root CA program enforcement and SA revocations. but the recent changes in the MS Root Certificate Jew-gram are now being executed under force, and they are not benign. they are forcing expansion of this single-point-of-failure hyper-dependency design, and doubling-down on a very bad idea.

for net security and medical data, i tightly monitor all outgoing application-rule white lists and allowed subnets for each. changes since 2015 are now forced into adoption by very fast certificate timeouts. websites are going dark, programs are failing, and ssl-vpns that form the basis of client mgmt and roaming workers won't form tunnels. the spread is affecting all those who won't pay for refreshing re-cert or move to new sa, which happens to be alot of oss/free/old-tard software and hardware. worse still, compliance notices from the us department of justice and alphabet agencies are being circulated. microsoft is at the heart and center of this charge, and they are tightly in bed with these agencies. there is zero trust, forced to masquarade as 100% trust deferred to the proven worst management on the planet.

in before win10; all systems kept off win6.3/win10 kernels. gpo management has cert controls currently being explored. emerging/evolving attack surface. no satisfactory independant control yet achieved.

i post this here now, because i'm not seeing any complaints against this rising tide anywhere. nor solutions. anybody else out there seeing this? fighting this?

--
narrative:
--

--
reference:
--
20120101 - Manage Trusted Root Certificates (via GPO) (current exploration for solution mgmt)
https technet microsoft com/en-us/library/cc754841.aspx

20120611 - Windows Untrusted Certificate Updater (newer kbs, for reference)
https support microsoft com/en-us/kb/2677070

20150929 - Windows Root Certificate Program (24hr Auto Updater)
https support microsoft com/en-us/kb/3004394

20150629 - Microsoft quietly pushes 17 new trusted root certificates to all Windows systems
http www infoworld com/article/2941594/security/microsoft-quietly-pushes-17-new-trusted-root-certificates-to-all-windows-systems.html

20151217 - Microsoft updates Trusted Root Certificate Program to reinforce trust in the Internet
https blogs technet microsoft com/mmpc/2015/12/17/microsoft-updates-trusted-root-certificate-program-to-reinforce-trust-in-the-internet/

20160101 - Microsoft Trusted Root Certificate Program Requirements
https technet microsoft com/en-us/library/cc751157.aspx

--
problem:
--
auto-revocation lists are mandatory, black-listing production endpoints

--
narrative:
--

--
reference:
--
20120101 - Manage Trusted Root Certificates (via GPO) (current exploration for solution mgmt)
https technet microsoft com/en-us/library/cc754841.aspx

20120611 - Windows Untrusted Certificate Updater (newer kbs, for reference)
https support microsoft com/en-us/kb/2677070

20150929 - Windows Root Certificate Program (24hr Auto Updater)
https support microsoft com/en-us/kb/3004394

20150629 - Microsoft quietly pushes 17 new trusted root certificates to all Windows systems
http www infoworld com/article/2941594/security/microsoft-quietly-pushes-17-new-trusted-root-certificates-to-all-windows-systems.html

20151217 - Microsoft updates Trusted Root Certificate Program to reinforce trust in the Internet
https blogs technet microsoft com/mmpc/2015/12/17/microsoft-updates-trusted-root-certificate-program-to-reinforce-trust-in-the-internet/

20160101 - Microsoft Trusted Root Certificate Program Requirements
https technet microsoft com/en-us/library/cc751157.aspx

bump

bump because interesting

i haven't found out any new info. nor new awareness to compare notes with. this risk will have to be, for now. the compliance checks (countermeasures against opt out/ghosting on certs) offer no choice. made a shooting solution, deploying.

part one: ca management is now mandatory. working solution is based off of enabling cert asking and cert importing for interactive users. next, on the automation side, used cert ranking to add whitelist placeholders scripts at lower rank to stores. this way, the link is undetectable (cert lookups for revoke and add take first hit/match and exit): when shtf, the order can be scripted/altered. switch flipped.

part two is client firewall expansion. the rest is all firewall rule, with app and reverse-dns lookup. a bit tricky. had to find a client solution that could do deep inspection very quickly and not slow down packet load. the rule order is as follows:
(1) vary: scriptable high-pass filters for environment management
(2) drop: high filters to prevent ipv6 to ipv4 tunneling
(3) pass: green-light apps
(4) drop: red-light apps deny
(5) drop: url always-black lists
(6) pass: vary narrow ruled vpn management tricks
(7) pass: local protocol green-lights, very fine enumerated rules
(8) pass: local multicast ipv4 and ipv6 controls (some split into #7), very tight rules
(9) pass: local protocol with operating-system apps green-lights, splitting off printer vs kernel vs api rules
(10) drop: nonmatched #7 inet protocol corollary
(11) drop: nonmatched #8 bcast traffic corollary
(12) pass: url switch lists (enable/disable place holders, e.g. winupdate on when needed, off otherwise)
(13) pass: url always-white-lists (crl and oscp always on, unless on blacklist)
(15) drop: #9 inet protocol to operating system corollary (ordering permits selective whitelist crl/ocsp to work, the forced compliance check pass), separated as before
(16) vary: security mgmt black listed apps that control changing the rules, drop by default, scripted
(17) pass: security mgmt local only
(18) pass: security mgmt net other
(19) vary: inet update applications, winupdate, security update, etc. drop default, scripted mgmt
(20) drop: security mgmt other
(21) pass: green-light tunneling tcp-protocols eg ssh
(22) ask: all other app
(23) drop: all other app catchall
(24) drop: all other catch all

5 days straight. good enough for now. structured to facilitate updates to fine tunning. overall solution should have enough adaptability in it. some logging to check if things are doing what they're supposed to, or not doing what they're not supposed to, etc.

endpoint reached: cert control restored when needed and hidden otherwise.

endpoint reached: compliance to low-level operating systems selectively on, impossible to stop, but tailored. controls to prevent the worst. script points to adapt quickly. control over updates restored, permitting intermittent ghosting between forced update events.

interest still open, if anyone cares to take the floor.

#18 is a edit mistake, delete.

My hope for the solution to this is Namecoin (or another de-centralised blockchain-based solution).

The Cert gets stored in the blockchain.

Is there hope in a distributed web-of-trust model?

no. this isn't a storage problem, nor a delivery problem. the internet and computers at large have those squared away.


web of trust is the model, which relies on every one doing their part of their work, and -then- doing the network maintenance work of that web. both parts were, since inception, never done to correction nor to completion for the 80-90% cumulative distribution. the work won't be done now either. the model must take into account, the rising theft and lying corrupting institutions. the model must take into account, failed work in programs, drivers, chips, etc as well. the model must take into account, the rolling window of time that transpires, which permits the lies to sound good, until they don't, and the debt comes due.

there is no substitute for choosing bad hardware, and no one can nor should be shielded from the risk. there is no substitute for choosing bad software, code, scripting, and drivers. and no one can, nor should, be shielded from the risk. the stupidity of others is a massive ledger of ever increasing debt of work, deferred and 'trusted' along -- but there's nothing there, all smoke and mirrors. if you have no ability to verify any of these things or components, then you can't possibly ever trust them. claiming trust on said components is thus also a lie, a debt of nonwork extended a line of credit that does not exist. as time ticks away, and enough proof of nonwork comes out, then the debt comes due and defaults. both the debt of failed component, and the debt of failed trust. because the component was always chicken-shit, and the trusting of chicken-shit-or-not-shit was also always shit (just it's own turkey-shit).

don't touch stupid. it is time-debt. and i will not pay my time to you, or anyone else, for their stupid. this goes for components. this also goes for networks of lies.

xcoin is a transaction network model that votes on the transactions -- after and only after someone else does all the work for (1) a public rare 'coin'/cpu-seconds-worked-as-a-hash, (2) a signed pki transaction between to authenticated-but-unvalidated-accounts. the vote is on whether or not the coin is a coin and the transaction (coin history edges) is verified. that vote is not on whether or not xcoin is a good coin algo. that vote is not on whether or not xcoin is a good coin network, or architecture, or code base.

hopefully all who read have spent the time to re-read and re-read. moving on.

a network can be made. but it's your internal network, not mine. and each node must to its own work to authenticate each component that its production relies on, and the work work to authenticate-with-history the edges that box (delivery).

server/website/delivery: a server has a url. it also has its own s.pki. it signs a list of urls. it also signs a very long unique scoin.

the client has its own c.pki and unique c.coin. it also keeps a history of server s.urls and s.coin. at first encounter, the client observes and remembers s.publickey, s.certificate/coin, and s.urls. it then must do the work to check the uniqueness of s.cert/coin. it has already done the work to check the s.url access point (the access is the proof). now the client must compare its own internal history proof record to: (1) notice if anyone else has that url, that cert, or those hashes on them, and (2) reject or rank the client history trust accordingly.

the purpose is only to verify that past and present are the same server delivering or accepting delivery. from this completed computation, the history edges may be expanded upon again by including the time in each hash stored in history. that's it.

take this and now apply it components. again, the client generates its own internal-only-never-shared-with-anyone internal-transaction-network of accessed-resources (time-stamped urls/programs/drivers/etc verified as 'live').

i don't need to do the impossible task of verification/validation of physical address/personhood. i just need to keep acccount of each (1) delivery-access-encounter, (2) the cert/coin it carries, and any relevant (3) alt-access-encounter the server/resource says is also that server/resource, which i will then do the compute work of network account upon access.

note that the choice to accept/participate with an edge or component is not addressed. this is independent of the internal access-history-'network'. if the client don't want to trade with alice/bob/charlie, they don't. or do. their choice. no substitution for poor choice/access/accept.

salvation bump.
goodness detected.
have not had time to read.

bump

Interesting but over my head

Very surprising for this board, keeping on the front page.

Some suggestions on how to hopefully increase integrity and authenticity.
Place the s.pki and c.coin (the items) in a un-indexed (different (everyone), write (root) partition) and is passed as a variable so that a robot.txt bypass won't find it. In addition the filesystem of that partition that doesn't have a journal so that shred can work correctly if the need arises.

Also to help ensure that the items could have only been created on the machine it could be signed with a sign only GPG pair using sha512 and serpent with >150,000 rotations.
To minimize the speed impact the creation and signing process will be run in memory (/dev/shim, I believe).
Same situation hopefully with the client side.
Possibly hashed with sha512, with the result then piped into a text file. This text file is then GPG signed using the same process outlined above. The signed file and the sha512sum inside are checked on a user configurable time (default, every hour).

Dexus bump.

Try /g/, the windows tech board.

Your post is almost incomprehensible, but I seriously hope you didn't expect any kind of security using Windows.

What exactly are you referring to?

20160101 - Microsoft Trusted Root Certificate Program Requirements
https technet microsoft com/en-us/library/cc751157.aspx

--
please re-read if you are behind. please re-read, regardless. the target is set, the object is to win, the method is to develop an adaptive solution/response that can track with the increasing malice (to business) from our friendly (in their eyes) poz'ed idiots and their imported minions running the show.

the landscape is set. increasing frequency of revokes (crl) and new/re-issue (oscp) across program, driver, and website keys. while linux and bros can think they are immune, that's a bit of a cop out to avoid work/fighting; they will be affected by this too with browser packaged root certs trust stores. again, it makes gwx/win10 look like a cake walk distraction. again, it is unsolved but 'contained'. again, the idea is how to maintain business independence to decide it's own tools, regardless of what skypeople say, regardless of os.

as an aside, i'll agree to add more fluff words, mushy sentences, proper caps, and general goy dumb-downs to make my messages more appealing to your comprehension. but only to a point. and my agreement will be revoked if you don't step up to fulfill the credit i give for you to improve yourself.

Heard something similar being mentioned on the no agenda show relating to certificates that most people here can relate to. If you're not using https on your site a big scary error warning will popup calling it unsafe on most browsers.

Some average guy running a simple website with nothing important on it shouldn't have to worry about complying with TLS. He already has to pay for hosting and registration, now there's a certificate authority that wants a cut as well? Goodbye thousands of small unique sites, they'll use a 'free' service instead. Who would bother hosting something like Zombo.com these days? The internet is quickly becoming homogenized, your typical business will have a facebook page not a website nowadays.

They're saying it's being done by advertising agencies. They want to stop ISPs that remove ads and inject their own and eventually prevent any form of tampering to web content. Seems plausible to me, as we're seeing with the Brave browser this area is already a battlefield.

People are seeing this but the fight for freedom on the internet has been lost. It's only going to get worse moving forwards.

Unfortunately you operate on a different (i.e. sensible) priority system than everyone else on the planet.

Where I "live" it's only in the last 2 years that you can get anyone to bother adopting HTTPS at all. It's almost like the entire world has become the government and therefore everything we do is 10 years behind at all times.

interesting. thank you for the new info.