Post

Replies

Boosts

Views

Activity

Reference example of AppTest server-side implementation
Hi, We have a multi-platform application that requires integrity attestation before the backend will enable supporting services (fairly common scenario). I've read the documentation for DeviceCheck and AppAttest, as well as SafetyNet on the Android side. The Android documentation includes lots of examples of use, including server-side (though oddly in C# and Javascript... which I don't see as being server-side languages, but... oh, well). Anyway, maybe there's a server-side example of using an application attestation on the server when validating a client, as well as validating individual requests with assertions, but I've not been able to find it. It seems like a relatively important bit of functionality to ensure that apps aren't being compromised, while at the same time requiring a correct implementation... Why not give a reference implementation as a starting point to make sure developers are on the right path? Can anyone point me at an example as a Gist, etc? Thanks.
4
1
4.8k
Oct ’23
Mail.app and weird HELO greeting
Hi, I was looking through our MTA logs and I noticed that the MacOS client sends: HELO smtpclient.apple when it should be sending: HELO my.fq.dn or if it has no meaningful mapping to a domain name, at least: HELO [192.168.1.19] Per RFC-2821: 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command. This seems pretty straightforward; why is the standard not being followed? Just double-checked: the iOS client does the same. If they all send the same meaningless string, this makes reading logs that much harder. Should be trivial to fix. Thunderbird had a similar bug, but I fixed that 15 years ago. Why diverge from the standards? SMTP is one of the easier RFC's to implement. Thanks, -Philip
3
1
2.8k
Nov ’21
Reference example of AppTest server-side implementation
Hi, We have a multi-platform application that requires integrity attestation before the backend will enable supporting services (fairly common scenario). I've read the documentation for DeviceCheck and AppAttest, as well as SafetyNet on the Android side. The Android documentation includes lots of examples of use, including server-side (though oddly in C# and Javascript... which I don't see as being server-side languages, but... oh, well). Anyway, maybe there's a server-side example of using an application attestation on the server when validating a client, as well as validating individual requests with assertions, but I've not been able to find it. It seems like a relatively important bit of functionality to ensure that apps aren't being compromised, while at the same time requiring a correct implementation... Why not give a reference implementation as a starting point to make sure developers are on the right path? Can anyone point me at an example as a Gist, etc? Thanks.
Replies
4
Boosts
1
Views
4.8k
Activity
Oct ’23
Mail.app and weird HELO greeting
Hi, I was looking through our MTA logs and I noticed that the MacOS client sends: HELO smtpclient.apple when it should be sending: HELO my.fq.dn or if it has no meaningful mapping to a domain name, at least: HELO [192.168.1.19] Per RFC-2821: 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command. This seems pretty straightforward; why is the standard not being followed? Just double-checked: the iOS client does the same. If they all send the same meaningless string, this makes reading logs that much harder. Should be trivial to fix. Thunderbird had a similar bug, but I fixed that 15 years ago. Why diverge from the standards? SMTP is one of the easier RFC's to implement. Thanks, -Philip
Replies
3
Boosts
1
Views
2.8k
Activity
Nov ’21