So I am looking into pingidentity.com (the author system in use) to see if they have API docs. Why reverse engineer if you can find a spec, right? I think I saw some requests earlier indicating that it was OAuth, and I see that is a supported federation standard. It looks like they have lots of API docs. The next trick will be to identify which one matches the particular product in use for the system I am trying to integrate with.
Follow up from last night's web adventures: the login process is a 4-step process
1. Provide username
2. Provide username, password and some things obtained from step 1
3. Authorization ping
4. Callback to get the cookies
The first two steps were pretty easy, but making this authorization ping is not. The request for #3 uses data (path and params) that was not seen in the response from step #2. I expect there is some transform happening in JS. I don't want to deal with reversing minified JS...
Ouch. @briar doesn't expect to have a mailbox until Dec 2022 (from mailing list). That seems like a long time for a store and forward service, but they'd have a better picture of all the implementation details than I do.
I know some people are still upset about the original HP ENVY lines being discontinued in 2012. https://en.m.wikipedia.org/wiki/HP_Envy
Just remember, you can still get the original HP in your local grocery store. I hope this offers some consolation.
In related news, TIL HP sauce is a thing.
This song really struck a chord with me.
Beethoven chills with Skrillix vibe
It's a top contender for me. I made notes on the ticket I have for implementing secure, self sufficient messaging. I use Signal every day, and it rarely has any problems, but we want to be self sufficient. This could mean running a Signal server of our own. It could mean improving Briar's client to support basic features like self deleting messages or the ability to ever delete a blog post for that matter. But If there is a better alternative, I'm certainly interested in giving it a try.
Some things I like:
- Standards based
- Open spec, open source implementation
- No phone numbers
- Federated (can run one's own server)
- Multi-device support
- Perfect Forward Secrecy
- Plausible deniability
- File transfer support
- Image support
Things I dislike:
- Not e2ee all the time (or even by default by the looks of it)
- Doesn't look like it has voice nor video support
I can use my Jitsi server for voice and video, so the those isn't a huge problem.
After a skim, it doesn't look like there are any major findings that weren't corrected before the report was released.
This says a lot. The reviewer was clearly qualified and took the time to go through the details. A lot of times I read public reports like this and think "they clearly hired the lowest bidder just so they could say they passed a 3rd party security audit" but that wasn't the feeling I got at all here.
Now I'm even more interested in Conversations.im
The author describes omemo as a wrapper around the Signal protocol, then proceeds to point out that there is a lot of talk about the Signal protocol, but no real specification document like an RFC. They then go on to talk about how they compared the omemo spec to Signal's protocol, citing their sources.
The report starts with critical remarks of the omemo spec not having specific design goals because it means it's not clear what security guarantees it is trying to provide. Spot on!
The report was not written by a company that is famous for finding bugs in cryptographic algorithms or implementations. It was written by someone I'd never heard of. At this point I was skeptical, but I was still willing to give it a chance.
I skimmed the entire thing, reading some sections very carefully (the things that are typical gotchas in secure messaging). I was impressed. The report showed the person doing the audit clearly understood their protocol as well as the things to look for.
A while ago someone mentioned conversations.im to me and said it was basically a standards based, federated version of Signal, which also means not having to fork over phone numbers to a 3rd party provider, as benevolent as they may be.
Today I looked into it a bit more. Messages are optionally protected by this omemo protocol. https://conversations.im/omemo/ I clicked to find out more.
They said the protocol passed a 3rd party audit. I clicked to find out more...
For those of you who tuned in to last night's live stream, I figured out the issue we were facing. It wasn't frozen, it was just slow. I haven't solved the slowness, but by increasing the timeout I was able to get it to complete the installation.
I've deleted the pool and recreated it with more robust settings and I am currently creating base images. Looks like we should be good to go.
On this week's stream: live migration and high availability!
Does anyone know if it is possible to have versions of a Proxmox template as can be done with Vagrant base images?
I can't find anything about it in the docs, but it seems like a pretty standard feature of a hypervisor that uses the concept of base images.
I want to be able to create a base image and then update it monthly to reduce the number of patches that need to be applied at deploy time.
I know someone who founded a company with the goal being to get everyday people to be able to get their computing devices to do what they want, without having to become a programmer (at least, in the traditional sense). They are adamant about cutting out complexity!
If anyone is interested in supporting a sustainable computing project, eoma68 has been around for years. They have been working out manufacturing issues for a long time and it's impressive to see them sticking with it. There is a lot of passion and community there.
I don't know who needs to hear this, but I can help you test your so-called offensive cyber tools.
@thegibson This Mimecast service called "sync & recover" sounds like it's a backup service. https://www.mimecast.com/products/cloud-archive/sync-and-recover/
It appears that Mimecast accesses Microsoft's Office 365 server and copies all versions of all documents. Why would companies:
1. Give their data to Microsoft
2. Give it to Mimecast, and
3. Expect it to remain safe
It's because secure backups are tedious to implement. It's far easier to pay someone to deal with this. If that's an acceptable risk, that's fine.
I like figuring out how things work. he/him
Mostly hackers, mostly in Urbana, IL, talking to each other & our friends on like-minded servers without giving our personal data to the marketing machine.