Are there cryptographical flaws in this e2ee website chat widget? For a product I'm developing I want to verify if the thinking behind it is cryptographically strong and secure. The product is a chat widget on websites of customers. Like an e2ee version of Intercom.

There are 3 parties that will connect to the service:


Customer of the service (i.e. user of the service I will offer)
Service that offers the chat widget + tools for its customers
Visitors are people that use the chat widget


A few features that are important for the product are:


The service should not see the content of messages send between customers and visitors
The traffic between service and customer and visitor are encrypted via SSL. In this product only important the service can't read the messages
The visitor does not have an account with the service
The customer has an account with the service
The customer can reply to chats from multiple devices
The encryption and decryption should be done in the browser of the customers and visitors only. It will rely on the SubtleCrypto API
The messages include a session ID so both users can verify if following messages are from the same sender


I created a diagram with all the steps I think I need to take:



Diagram explained


To be able to use the same public key on multiple devices of the customer it needs to be copied to other devices of that same customer.


The customer logs in the service with their password
We use the password to create a PBKDF2 key in the browser (key stretching)
We generate a RSA key pair 
We encrypt the private key with wrapKey with the PBKDF2 key with AES-GCM 256 bits (the service will not have access to the decrypted private key)

Send the encrypted the private key and public key of the customer to our service
The visitor also creates a key pair with RSA-OAEP
The visitor sends the public key to our service
The visitor gets the public key of the customer from our service
The visitor includes a session ID in their message and encrypts it with the public key of customer
Visitor sends encrypted message back to service
Customer receives encrypted message and public key of visitor
Customer decrypts message with their own private key and encrypts message for the visitor with their public key
Encrypted message is send from customer to service
Encrypted message is send from service to visitor
Visitor decrypts messages from customer


Known flaws


The customer can't verify who the visitor is unless the visitor identifies themselves. This is totally fine for our service


What are there other cryptographic flaws in this e2ee service?
If the customer sends his public key to the business, then the business creates a new set of keys forwarding the new public key to the visitor then the business now has a way to decrypt messages from the visitor since the visitor is not aware that the public key is not the intended customers public key but the new one generated by the business.  The business now can decrypt all messages from the visitor to the business making any changes they wish and using the customers original public key to re-encrypt the changed message with the customers public key and passing that message along to the customer who is not aware that the message has been changed.  If the business does this with the public key of the visitor passed to the customer as well then messages can be read and changed in the opposite direction as well.  This is a classic man in the middle.  That is what TLS is designed for an encrypted communication channel directly between the visitor and the customer with no relay between the certificates for TLS can be verified through a certificate authority which both parties have to trust for the initial key exchange to take place.  In this scenario the business is trying to act as a trusted man in the middle however it maybe the intention to have the business act as a certificate authority  who signs both the businesses and visitors certificates or public keys to ensure that both parties are receiving the intended keys.  In order to do that both parties should have the businesses certificates installed as trusted certificates authorities on their systems which is not a great idea and can lead to major compromises in practice.