我想知道使用GWT和SSL（实际上是在JBoss web-app服务器上配置TLS）的安全漏洞（如果有的话）是什么。我和我的朋友讨论了这个问题，他说，即使我启用了HTTPS，一些恶意用户也可以拦截我的.js并更改代码并在服务器上进行身份验证。我们假设除了SSL之外我们从不在线上发送纯文本密码（我们首先哈希）。这真的有可能吗？
我想知道的另一件事是 - Javascript代码（由GWT生成）如何激活RPC调用？我们使用Wireshark来嗅探客户端到启用SSL的Web服务器的请求和响应，并且没有任何RPC包。我们所看到的只是这些TLS协议数据包，我们可以通过在客户端和Web服务器的源和目标IP地址上使用过滤器来轻松识别它们。
如果您还通过HTTPS发送.html和.js文件，那么 - 一般来说 - 没有人能够在传输过程中操纵它们。当然，还有一些实际问题：
我们假设，事实并非如此。但是你的声明是：
我们假设除了SSL之外我们从不在线上发送纯文本密码（我们首先哈希）。
所以你不通过SSL发送所有内容？那么，您通过SSL发送的内容可能会在转移过程中被盗和操纵。我假设，你的朋友的意思是，哈希的密码可能被盗！即使攻击者可能无法重建明文密码，如果您的服务器接受哈希密码，他也可以简单地使用哈希密码。
另见我对GWT/Javascript client side password encryption的回答。
关于你的第二个问题：
我们使用Wireshark来嗅探从客户端到启用SSL的Web服务器的请求和响应，并且没有任何RPC包。我们只看到这些TLS协议包...
好吧，我真的希望如此！您的RPC调用是这些数据包的加密有效负载。如果你可以为Wireshark提供私钥，你可以使用Wireshark's SSL dissector来破译包（使用生产密钥时要非常小心！）
为了完全确定您的SSL / TLS配置，我建议您使用一些外部工具。到目前为止，对我来说最准确的是SSL/TLS Server Test。在那里，您可以看到您的配置如何符合PCI DSS要求，或HIPAA和NIST的指南，这些是保护SSL / TLS的行业标准。