encryption for com_connect

marios2 · 2021-01-27 19:06:05

According to the GDPA guidelines ( DSGVO here in Germany) personal data, like emails and phone numbers you should use encryption, when sending this info over the internet from a contact form.
I did some digging and found that such a plugin does exist for wordpress, which is written in javascript, but it uses PGP ( which I believe is proprietary ).

Would it be possible at all to adapt com_connect , so it dose encrypt this data?
What this basically means, is that you need to generate two private keys and two public ones. One on the server side and one on the email client of the site owner.
May be this could be done with GnuPG, which is open source.

Would there be someone, who would like to adapt this plugin? I would be willing to payroll this.
I can pay by wire on an IBAN Account.

Thanks in advance,
Rgrds marios.

jakob · 2021-01-27 19:51:02

Is not regular SSL (https and a valid certificate) sufficient for regular information such as telephone and email? I’d understand the need for keys for bank transactions or sensitive personal health data but for normal form queries that seems extreme?

Bloke · 2021-01-27 20:31:58

I’m not entirely sure how to adapt com_connect to do that. When a website visitor lands on a contact form and chooses to send a message to a site owner for, say, support or to ask for info on a product/service, how would com_connect (a server-side script) be able to create a key pair in the recipient’s computer – let alone email system?

I’m up for experimenting with writing com_connect modules to encrypt the data that is sent to the server for storage in a database, but to encrypt the contents of the email seems pretty hard to do. It would involve pre-computing key pairs, surely? Maybe the user would have to upload their public key to the server so it could generate a corresponding server key so messages could be encrypted/signed before delivery?

That’s probably doable for single messages but what if the to attribute is changed to multiple recipients (which is allowed) and one or more of those don’t have a key set up? What’s the point of sending a message from a site visitor securely to one person and not another? Surely the weakest link in the chain is the person who chooses not to encrypt their messages?

Not saying it’s impossible. Just needs some scope and to be thought out so it’s not wasted effort.

marios2 · 2021-01-27 21:30:15

jakob wrote #328365:

Is not regular SSL (https and a valid certificate) sufficient for regular information such as telephone and email? I’d understand the need for keys for bank transactions or sensitive personal health data but for normal form queries that seems extreme?

No, regular ssl and cert is not sufficient for contact forms, because the form data once posted from the user is not encrypted while traveling to the e-mail client. That’s why you use a command line tool which contains the algorithm to generate a key pair for e-mail encryption.

I have a book about DSGVO from a german law firm, and in section 4.21 titled :
Is it still possible to use contact forms?…
it says, that you do not need an opt-in/authorization from the user, but then states….

you have to note though that the data should be encrypted.

rgrds marios

Last edited by marios2 (2021-01-28 09:22:15)

marios2 · 2021-01-27 21:52:08

Bloke wrote #328366:

I’m not entirely sure how to adapt com_connect to do that. When a website visitor lands on a contact form and chooses to send a message to a site owner for, say, support or to ask for info on a product/service, how would com_connect (a server-side script) be able to create a key pair in the recipient’s computer – let alone email system?

I was thinking, may be some kind of set-up page, where you generate the server-side key pair.
The Site owner must generate his own key-pair and set the whole thing up, in thunderbird.
As far as I understand this, the exchange of the public keys is needed only to happen once, from then on the decryption can happen automatically in Thunderbird.

I’m up for experimenting with writing com_connect modules to encrypt the data that is sent to the server for storage in a database, but to encrypt the contents of the email seems pretty hard to do. It would involve pre-computing key pairs, surely? Maybe the user would have to upload their public key to the server so it could generate a corresponding server key so messages could be encrypted/signed before delivery?

The Data shouldn’t be stored in a database, as this would require an opt-in. The only thing we are concerned about is the travel-route of the data from the Server to the e-mail client.
May be it would be possible to package up GnuPG somewhat in a plugin, I don’t know.
I wonder why the wordpress plugin is written in Javascript. May be, because it wasn’t possible to do this in PHP? I don’t know yet, I will investigate further.

That’s probably doable for single messages but what if the to attribute is changed to multiple recipients (which is allowed) and one or more of those don’t have a key set up? What’s the point of sending a message from a site visitor securely to one person and not another? Surely the weakest link in the chain is the person who chooses not to encrypt their messages?

I only need it for one e-mail address, which is the site owner, in this case info@dianaburg.com, although this is also on the server so to speak.

Not saying it’s impossible. Just needs some scope and to be thought out so it’s not wasted effort.

Yeah, Sure… in the meantime I will just scrap the contact form altogether and put the email address on the contact page.
Then you don’t have to do anything.

Regards marios.

Last edited by marios2 (2021-01-27 21:57:46)

marios2 · 2021-01-28 09:24:32

I did some digging and it seems that Thunderbird does no longer support GnuPG with Enigmail.
However it does support OpenPGP and you can import your keys from the settings.

colak · 2021-01-28 09:54:49

Hi Marios,
I assume that most visitors will not be using thunderbird or even know how to create encryption keys. I think that the law firm you received the advice from has no idea of the real world.

Having said that, if you are working on a site that receives sensitive information, maybe the wikileaks site should be of help regarding providing some ideas.

jakob · 2021-01-28 10:12:49

marios2 wrote #328367:

No, regular ssl and cert is not sufficient for contact forms, because the form data once posted from the user is not encrypted while traveling to the e-mail client. That’s why you use a command line tool which contains the algorithm to generate a key pair for e-mail encryption.

If you use TLS and the corresponding SMTP port for sending the mail, would that not cover the encrypted transport to your client’s e-mail server? Textpattern would need to be able to send with these details.

If you can’t use a contact form but your client needs to be contactable (usually the purpose of a website), the alternative would be to provide a “send me an e-mail” link and that too would not use PGP.

Your issue is discussed here and while the source is probably not authoritative, the Datenschutz Consultant comes to the conclusion (citing the relevant paragraphs of the DsGVO) that SSL+TLS is the currently available reasonably realisable technology.

All this of course relates to typical contact form uses. Anything truly sensitive may require a more secure system anyway. Off the top of my head, might a conceivable approach be to save the relevant data from the contact form encrypted in the textpattern database (so non-readable) and to generate an unlock key that is sent to the contact form recipient (the client) so that they can then read the data from the database.

Bloke · 2021-01-28 11:51:12

jakob wrote #328372:

save the relevant data from the contact form encrypted in the textpattern database (so non-readable) and to generate an unlock key that is sent to the contact form recipient (the client) so that they can then read the data from the database.

Yeah, that’s the sort of thing to which I was alluding above. I’m not entirely sure of the specifics or if this is even technically possible because the message stored needs to be readable by two parties: the client (if they want to see what they wrote) and the site operator (to answer the query).

Without checking, I don’t know if content can be encrypted (and/or signed) with dual public keys so it can be readable by more than one person’s corresponding private key. I seem to recall that PGP could, but that was a long time ago. If that’s not possible then generation of a one-time key that is mailed to the client and administrator(s) (specified in the ‘to’) field might be the only approach.

Central storage of the information in an encrypted format that is only accessible by both parties seems like a more viable solution than trying to encrypt the content for transmission back to the client (so they have a copy of their request) and encrypt the content again for the administrator(s) (to action).

Depends on the needs. It does seem overkill for a contact form, but a module for some kind of secure storage and access might be handy.

I would think it’s technically possible to utilise smd_access_keys for this, btw. In the thanks_form, generate a unique key with <smd::access_key /> and simply store the contact form content in, I dunno, an article in a pageless section. You could use a custom field to store the token (for later matching/retrieval) in the article when it’s written to the database, or simply stash the article ID in the key’s extra data.

There’d be no access to these articles by anyone from the public side (no page = no way to display anything). On the back-end, a tiny three-line plugin could hide articles in that section from the Articles panel, with only the Publisher being able to see them.

Access to that resource would be through the link to a protected page that’s mailed as part of the key to the client (and admin(s) in the ‘to’ field). When clicked, if the key matches, fetch the corresponding article and show it.

Bonus points if the article content itself can be encrypted somehow using the smd_access_token as a key. That would prevent anyone such as a Managing Editor (the only other privs that can access the Plugins panel) from shutting off the three-line plugin so anyone could view the articles from the Articles panel. And also prevents anyone with PHP access from writing a two-line script to fetch the article content from the textpattern table or from fashioning a <txp:article_custom> tag to get at the content, thus protecting it if the database itself is compromised.

That seems totally doable and doesn’t even require any custom tech, beyond:

The titchy plugin to prevent casual observers from seeing the articles (if required).
A call to smd_access_keys to generate the unique token.
A jot of PHP to either a) generate a key pair on-the-fly using the smd_access_key generated above as decryption token allowing the content to be encrypted for storage, or b) encrypt the content using the unique smd_access_key itself as a seed.
A call to etc_query/smd_query to insert the form content into the database.

All of that can be done now, most of it through the thanks_form.

Last edited by Bloke (2021-01-28 11:56:42)

marios2 · 2021-01-29 19:42:42

jakob wrote #328372:

If you use TLS and the corresponding SMTP port for sending the mail, would that not cover the encrypted transport to your client’s e-mail server? Textpattern would need to be able to send with these details.

I am not so sure. I have to admit I lack the expertise to have a correct judgment on the topic.
If I use a contact form on a site, which uses a CERT and SSL / TLS and post my message from this, then how does it travel? Does using SMTP cover encryption while it travels from a mail server to a specific mail client on your computer?

I mean, why on earth would WP have a dedicated plugin for e-mail encryption of contact forms, if it wouldn’t be for the GDPA guidelines?
( also note, that each EU country has some different implementation of this )

rgrds marios.

Last edited by marios2 (2021-01-30 01:56:52)

marios2 · 2021-01-29 19:55:00

colak wrote #328371:

Hi Marios,
I assume that most visitors will not be using thunderbird or even know how to create encryption keys. I think that the law firm you received the advice from has no idea of the real world.

Having said that, if you are working on a site that receives sensitive information, maybe the wikileaks site should be of help regarding providing some ideas.

Well, the Thunderbird Browser and encryption keys are only needed for the Site owner/admin.
Note, that the proposed encryption is happening transparently, the visitor / contact form user does not get involved in the encryption process at all.

regrds marios

Bloke · 2021-01-29 20:27:55

marios2 wrote #328406:

Note, that the proposed encryption is happening transparently, the visitor / contact form user does not get involved in the encryption process at all.

Yeah. If the server admin has added their public key to the database somehow, then it’s a cinch to intercept the com_connect deliver process and pass the message content through a one-way encryption process using the corresponding key and then send it on.

The tricky thing comes when you have multiple recipients. And also if you intend to deliver a copy of the message to the client, as some people do. com_connect allows for both those scenarios, and whatever module we introduce needs to be compatible not only with your narrow scope of “one recipient, no copy” that you need, but also the other, more general purpose, use cases.

The plugin can hand off to a module to do the encryption, but it can’t send it back to the plugin for processing if that message is destined for more than one recipient. The plugin is set up that it sends the same message to all parties.

The encryption module would have to iterate over the $to list and, for each user:

Look up the user and see if they have a key stored.
If so, encode the message using it.
Send the encoded version of the message to that recipient.

Repeat that for each $to and then signal back to com_conect to skip the sending portion (as the module has handled it).

The sticking points are:

If one of the administrators doesn’t have a key, what do we do? Send it plaintext (thus making the plugin deliver a false sense of security that the message is delivered ‘securely’ to everyone) or send it only to those admins that have a valid key stored (and risk one or all of them not receiving it, or not being able to read it if their key has been revoked/damaged and the old one is still stored in the DB).
The client (if a copy is sent) receives a plaintext version as there’s no way for them to supply their encryption key – unless the encryption module also adds a file browser/textarea for them to locate or paste their key in if they want a copy of the message encrypted to themselves.
What if the administrator clicks ‘reply’ in their email client and sends a reply to the client, quoting the original text (which most clients do by default). No encryption is likely to take place in this scenario (unless the admin has the client’s public key as supplied by them in the contact form) so all the previous security has been undone.

As I said before, I have no trouble exploring these options and it’d be a great exercise and a handy module if we can reconcile it all. We just need to think it through to catch all the edge cases and scenarios that the plugin can be used for.

Last edited by Bloke (2021-01-29 20:29:35)

Textpattern CMS

Textpattern CMS support forum

#1 2021-01-27 19:06:05