[crazy][spam][crazy][spam] [thread for further deliberations regarding akash certs]
it's something like ((((should we try to hack every provider on akash ??????)))) ((((i don't know! it sounds a little confusing? i don't know if they're vulnerable!)))) basically the idea of a cert simply not be validated is very far-fetched, combined with my very high prevalence of making mistakes, that it doesn't seem that serious to me but i don't see how the server is validating client certificates, and it's a little possible that they're all fakeable
one of the arguments is kind of like, if they are all vulnerable, then basically somebody will dump all their akash, short everything, then break all the providers, and buy low while it doesn't function during the downtime, and make a lot of money and it can be a lot better if it's you doing that than somebody unknown viewpoint likely influenced by mcboss stories
[it also gives you an option to do it kindly, explaining to everybody what is going on, and letting them make a killing too if they're able to and interested] [it does sound really not good though, for everybody to have their plans not work [confused, how is this a mistkae? maybe it is? basically we want people ot be happy, but not for bad things to be happening; it's sad the lack of general communication, very very sad; maybe the addition of communication is helpful dunno :)]] uhh the information on akash rates is that a provider costs like $10 for a straight month and that can be broken down into tiny subcents for just a few minutes of use, so it's very cheap to just run a process on a remote host
oh also the $10/mo is for providers that have been audited by the akash team there are other providers that i haven't looked at since i don't use it much and have security issues, that could for all i know be as cheap as free
and the $10/mo is for the random server specs i have put into my test yaml. it likely costs more or less for different machines :S sorry
I'm trying to write a small akash client. While discerning part of the protocol, I posted the three-post https://lists.cpunks.org/pipermail/cypherpunks/2023-July/115544.html which describes a potential vulnerability where a mitm can fake servers. I have not tested it, and am using a compromised system that often indicates mutated web content. I opened an issue for it. Curiously, I also looked up certs the other way around -- server validating client. I don't see this being done either, but have looked at it less in depth. This second option would be very serious as any old person could log into anybody's server, and hence it's pretty unlikely that I'm seeing it correctly, and one could infer from that the first vulnerability may be nonexistent too. But it's possible they're there! The usual way to check a vulnerability is to try to exploit it. It's very hard for me to spend time pursuing tasks, so I have not done this at this time.
contraposing: - akash works with an experienced security auditing team to vet providers - the akash code appeared to me to not validate certificates for offchain communications
[i get 'could not resolve host' trying to visit the akash auditor's website, https://www.moultrieaudits.com/ ]
On 7/20/23, Undescribed Horrific Abuse, One Victim & Survivor of Many <gmkarl@gmail.com> wrote:
[i get 'could not resolve host' trying to visit the akash auditor's website, https://www.moultrieaudits.com/ ]
[ i briefly visited the website more than a month ago and it loaded. ]
if we can relax around it, maybe we can find a way to report possible vulnerability [if present]
Boss: "just break into the servers of the people who work on the code and fix the security vulnerability" worker: "i don't know how to do that"
"i don't want to hear anytihng about security or anything!!!! i break into things on my off time so if you talk about it --"
the below text was unsent from 1 day ago: I reviewed the first issue again. [ insecureskipverify
some parts are thinking of rebuilding this, mostly for cypherpunks list where it would be appropriate to rebuild the use of exploits existing in the world (rational + list topic) i'm kind of stuck atm, i was on a road trip but i'm spazzing out at a rest stop for a while ... seems like adding an unknown would be unideal. other judgements around this also inspire it [[[working on code for the same service]]] <:S>
really, it's very likely, given my prevalence of mistakes, that i'm just missing how the verifications are performed
in my python code i verified the server cert :) it matches byte-for-byte the cert on-chain. assert peercertsubject['Common Name'] == self.__provider.address assert peercert.asn1.serial_number matching_certs = [cert async for cert in self.__provider.akash.akash_cert2.aCertificates( filter = dict( owner = self.__provider.address, serial = str(peercert.asn1.serial_number), state = 'valid', ) )] assert len(matching_certs) == 1 assert matching_certs[0].certificate.state == matching_certs[0].certificate.State.valid onchain_cert_pem = matching_certs[0].certificate.cert onchain_pubkey_pem = matching_certs[0].certificate.pubkey session_cert_pem = certbuilder.pem_armor_certificate(peercert) session_pubkey_pem = Booster._pem_armor_public_key(peercert.public_key) assert onchain_cert_pem == session_cert_pem assert onchain_pubkey_pem == session_pubkey_pem
[[[[i'm sorry it's not really example code for cert verification if such is sought, it uses homebrew libraries i wrote this past month [in https://github.com/xloem/smallcosmoscript or such] ]]]]
On 7/21/23, Undescribed Horrific Abuse, One Victim & Survivor of Many <gmkarl@gmail.com> wrote:
[[[[i'm sorry it's not really example code for cert verification if such is sought, it uses homebrew libraries i wrote this past month [in https://github.com/xloem/smallcosmoscript or such] ]]]]
[[[[ $ git remote -v origin https://codeberg.org/xloem/smallcosmoscript (fetch) origin https://codeberg.org/xloem/smallcosmoscript (push) ]]]]
[[[[[[[[[[[ the grpc code depends on my fork at https://github.com/xloem/cosmospy-protobuf/tree/grpclib-akash . each grpclib branch is a different package. with that installed, `await small.client.Client.acreate()` then makes a general-purpose asyncio cosmos chain client. it creates member functions for all the calls at construction time. ]]]]]]]]]]]]
On 7/21/23, Undescribed Horrific Abuse, One Victim & Survivor of Many <gmkarl@gmail.com> wrote:
[[[[[[[[[[[ the grpc code depends on my fork at https://github.com/xloem/cosmospy-protobuf/tree/grpclib-akash . each grpclib branch is a different package. with that installed, `await small.client.Client.acreate()` then makes a general-purpose asyncio cosmos chain client. it creates member functions for all the calls at construction time. ]]]]]]]]]]]]
significant information is missing here, it's not set up to be easy to learn
------------------------- [to repeat the problem, when i reviewed the provider client and server code for akash (partial report linked in second reply to [crazy?] tagged thread on this list) i did not see them verifying the other party's certificates. [this means a malicious party could log in]. _i make many mistakes and see many things wrongly_. the server code really looks wrong. [my highly paranoid guess as to what is wrong is that the certificate verification code could have been excised.]]
On 7/21/23, Undescribed Horrific Abuse, One Victim & Survivor of Many <gmkarl@gmail.com> wrote:
------------------------- [to repeat the problem, when i reviewed the provider client and server code for akash (partial report linked in second reply to [crazy?] tagged thread on this list) i did not see them verifying the other party's certificates. [this means a malicious party could log in]. _i make many mistakes and see many things wrongly_. the server code really looks wrong. [my highly paranoid guess as to what is wrong is that the certificate verification code could have been excised.]]
[sorry, it's the client code, which i looked at more, that really looks wrong to me, not the server code; the client code issue does not provide for malicious log in.]
i bumped myself again i'm working on the raw p2p protocol. the cometbft/tendermint protocol really prioritized resisting mitm and node isolation; [you can identify the address of every peer] [and this address is then used to generate the network session keys for communicating with them]. It's so satisfying to be working with a network that does that. The bump is the the tendermint servers have a behavior where they reuse frame memory for efficiency, and keep frames a constant size [but don't write padding bytes] -- {the data is encrypted with somebody else's ephemeral key though}
i bumped myself again
i'm working on the raw p2p protocol. the cometbft/tendermint protocol really prioritized resisting mitm and node isolation; [you can identify the address of every peer] [and this address is then used to generate the network session keys for communicating with them]. It's
On 7/29/23, Undescribed Horrific Abuse, One Victim & Survivor of Many <gmkarl@gmail.com> wrote: that is, the public key that is hashed to make the address, signs the shared key in the handshake
so satisfying to be working with a network that does that.
The bump is the the tendermint servers have a behavior where they reuse frame memory for efficiency, and keep frames a constant size [but don't write padding bytes] -- {the data is encrypted with somebody else's ephemeral key though}
it is nice that i am old enough that somebody is saying this clearly and overtly: https://github.com/tlsfuzzer/python-ecdsa#security **This library does not protect against side-channel attacks.** Do not allow attackers to measure how long it takes you to generate a key pair or sign a message. Do not allow attackers to run code on the same physical machine when key pair generation or signing is taking place (this includes virtual machines). Do not allow attackers to measure how much power your computer uses while generating the key pair or signing a message. Do not allow attackers to measure RF interference coming from your computer while generating a key pair or signing a message. Note: just loading the private key will cause key pair generation. Other operations or attack vectors may also be vulnerable to attacks. **For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key**.
On 7/30/23, Undescribed Horrific Abuse, One Victim & Survivor of Many <gmkarl@gmail.com> wrote:
it is nice that i am old enough that somebody is saying this clearly and overtly:
https://github.com/tlsfuzzer/python-ecdsa#security
**This library does not protect against side-channel attacks.**
Do not allow attackers to measure how long it takes you to generate a key pair or sign a message. Do not allow attackers to run code on the same physical machine when key pair generation or signing is taking place (this includes virtual machines). Do not allow attackers to measure how much power your computer uses while generating the key pair or signing a message. Do not allow attackers to measure RF interference coming from your computer while generating a key pair or signing a message. Note: just loading the private key will cause key pair generation. Other operations or attack vectors may also be vulnerable to attacks. **For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key**.
why cipherpunks write code: Somehow this information seems easily forgotten. What is possible in the world is based on what can actually be done. Generally, this is different from what people _say_ is possible, because they haven't tried it. Code shows what, on a computer, is possible. People who write code, see that many many things are possible. So, long ago, there were arguments around what was relevant or not, for example whether or not it is appropriate to secure a system. If you are familiar with writing code, you can tell whether a system is vulnerable or not, and know how easy it is to engage that situation. If you aren't, you are likely to instead be parroting misinformation from an oppressive body that is infiltrating things. Things that can be done by code can be done by _anybody_, _if_ they learn to write code. This is still true if a language model is writing your code for you. Nowadays we understand more clearly that many spy agencies will send people into security groups (there is a history of trying to send people into _all_ groups), and spread this misinformation, disrupting productive conversations on what is important to protect everyone's safety. We also understand more clearly that these people may have undergone intense trainings that cast misinformation as harshly true for reasons of protecting security. This misinformation pales in the face of real code, because real code says and demonstrates clearly what is actually real. Similarly, since _anybody can learn to use real code_, it is what is appropriate to protect against, when protecting security. This is why this project posts this information, and it is why the tendermint protocol cryptographically verifies every peer. Because what is possible, can and does actually happen, no matter how much misinformation is spread. And the only way to see that clearly is to get into the code, look for yourself, and write some code, and try it.
On 7/30/23, Undescribed Horrific Abuse, One Victim & Survivor of Many <gmkarl@gmail.com> wrote:
On 7/30/23, Undescribed Horrific Abuse, One Victim & Survivor of Many <gmkarl@gmail.com> wrote:
it is nice that i am old enough that somebody is saying this clearly and overtly:
https://github.com/tlsfuzzer/python-ecdsa#security
**This library does not protect against side-channel attacks.**
Do not allow attackers to measure how long it takes you to generate a key pair or sign a message. Do not allow attackers to run code on the same physical machine when key pair generation or signing is taking place (this includes virtual machines). Do not allow attackers to measure how much power your computer uses while generating the key pair or signing a message. Do not allow attackers to measure RF interference coming from your computer while generating a key pair or signing a message. Note: just loading the private key will cause key pair generation. Other operations or attack vectors may also be vulnerable to attacks. **For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key**.
why cipherpunks write code: Somehow this information seems easily forgotten. What is possible in the world is based on what can actually be done. Generally, this is different from what people _say_ is possible, because they haven't tried it. Code shows what, on a computer, is possible. People who write code, see that many many things are possible. So, long ago, there were arguments around what was relevant or not, for example whether or not it is appropriate to secure a system. If you are familiar with writing code, you can tell whether a system is vulnerable or not, and know how easy it is to engage that situation. If you aren't, you are likely to instead be parroting misinformation from an oppressive body that is infiltrating things. Things that can be done by code can be done by _anybody_, _if_ they learn to write code. This is still true if a language model is writing your code for you.
Nowadays we understand more clearly that many spy agencies will send people into security groups (there is a history of trying to send people into _all_ groups), and spread this misinformation, disrupting productive conversations on what is important to protect everyone's safety. We also understand more clearly that these people may have undergone intense trainings that cast misinformation as harshly true for reasons of protecting security.
This misinformation pales in the face of real code, because real code says and demonstrates clearly what is actually real. Similarly, since _anybody can learn to use real code_, it is what is appropriate to protect against, when protecting security.
This is why this project posts this information, and it is why the tendermint protocol cryptographically verifies every peer. Because what is possible, can and does actually happen, no matter how much misinformation is spread.
And the only way to see that clearly is to get into the code, look for yourself, and write some code, and try it.
Completely dropped this part: Because it is so easy to show what is true with real writing of code, the behavior of these oppressive bodies has been to suppress intelligent and free engagement and discussion of code in general. You can see this some near public security audits ... This is maybe most clearly prevalent in the history of this list, and its present state. Where I am the only person on it discussing writing code.
participants (1)
-
Undescribed Horrific Abuse, One Victim & Survivor of Many