String Concatenation

发表于 2022-08-26

今天看了个因字符串拼接导致的 CPU 高的问题，首先是监控 Agent 持续对一个实例进行告警，并抓取到了 CPU 高的相关 Java 线程：

lwpId: 17, CPU usage: 52.9
"G1 Concurrent Refinement Thread#0" os_prio=0 tid=0x00007fa73002e000 nid=0x11 runnable 

lwpId: 198, CPU usage: 47.1
"http-nio-80-exec-42" #188 daemon prio=5 os_prio=0 tid=0x00007fa71409e800 nid=0xc6 runnable [0x00007fa6c942b000]
   java.lang.Thread.State: RUNNABLE
  at java.util.Arrays.copyOf(Arrays.java:3332)
  at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
  at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
  at java.lang.StringBuilder.append(StringBuilder.java:136)
  at me.tianshuang.tool.StringUtil.listToString(StringUtil.java:433)
  at sun.reflect.GeneratedMethodAccessor1008.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)

阅读全文 »

FailedRequestFilter

发表于 2022-08-24

今天帮同事查了个参数丢失的问题，确认是由参数大小超过 Tomcat 默认限制引起，源码位于 tomcat/Request.java:

if ((maxPostSize >= 0) && (len > maxPostSize)) {
    Context context = getContext();
    if (context != null && context.getLogger().isDebugEnabled()) {
        context.getLogger().debug(
                sm.getString("coyoteRequest.postTooLarge"));
    }
    checkSwallowInput();
    parameters.setParseFailedReason(FailReason.POST_TOO_LARGE);
    return;
}

阅读全文 »

OpenSSH

发表于 2022-08-11

OpenSSH 8.8 存在不兼容的改动，导致 macOS 升级至 Ventura 后因 macOS 上的 OpenSSH 版本升级至了 9.0 后当连接的服务端 OpenSSH 版本为低版本（如：6.6.1）时 SSH 连接时无可互用的签名算法导致提示输入密码（服务端允许密码登录时）或者直接提示 Permission denied, please try again.（服务端不允许密码登录时）。如果使用 verbose 模式查看 ssh 时的 debug 信息，可以发现如下输出：

debug1: send_pubkey_test: no mutual signature algorithm
debug1: Trying private key: /Users/Poison/.ssh/id_ecdsa
debug1: Trying private key: /Users/Poison/.ssh/id_ecdsa_sk
debug1: Trying private key: /Users/Poison/.ssh/id_ed25519
debug1: Trying private key: /Users/Poison/.ssh/id_ed25519_sk
debug1: Trying private key: /Users/Poison/.ssh/id_xmss
debug1: Trying private key: /Users/Poison/.ssh/id_dsa
debug1: Next authentication method: password

建议的解决方案为升级服务端的 OpenSSH 版本，如果实在无法升级，则推荐修改客户端 ssh 配置临时启用使用 SHA-1 哈希算法的 RSA 签名。OpenSSH 8.8 Release 文档中关于此部分的描述如下：

Potentially-incompatible changes
================================

This release disables RSA signatures using the SHA-1 hash algorithm
by default. This change has been made as the SHA-1 hash algorithm is
cryptographically broken, and it is possible to create chosen-prefix
hash collisions for <USD$50K [1]

For most users, this change should be invisible and there is
no need to replace ssh-rsa keys. OpenSSH has supported RFC8332
RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys
will automatically use the stronger algorithm where possible.

Incompatibility is more likely when connecting to older SSH
implementations that have not been upgraded or have not closely tracked
improvements in the SSH protocol. For these cases, it may be necessary
to selectively re-enable RSA/SHA1 to allow connection and/or user
authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms
options. For example, the following stanza in ~/.ssh/config will enable
RSA/SHA1 for host and user authentication for a single destination host:

    Host old-host
        HostkeyAlgorithms +ssh-rsa
        PubkeyAcceptedAlgorithms +ssh-rsa

We recommend enabling RSA/SHA1 only as a stopgap measure until legacy
implementations can be upgraded or reconfigured with another key type
(such as ECDSA or Ed25519).

[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
    Application to the PGP Web of Trust" Leurent, G and Peyrin, T
    (2020) https://eprint.iacr.org/2020/014.pdf

Reference

OpenSSH - release 8.8
ssh(1) - Linux manual page

HTTP Hijacking

发表于 2022-08-08

最近查了个 HTTP 劫持的问题，本文简要记录。背景是近期不少用户反馈扫码出来的为黄色网站，由于历史原因，存在部分二维码的入口为 HTTP 协议，这部分请求通过 301 跳转至 HTTPS 页面实现。虽然已经启用了 HSTS，但是对于首次访问，始终存在被劫持的风险（域名未在 preload 名单中）。

阅读全文 »

System.nanoTime()

发表于 2022-08-03

最近查了个关于 System.nanoTime() 的问题，起因是业务里面将 System.nanoTime() 返回的数值作为了业务中的唯一值，最后发现了值相同的数据，询问编写这块代码的同事，同事反馈说当时编写的时候以为 System.nanoTime() 的精度很高，不会出现重复的数据。但是从现象来看，出现了重复的数据。

我们可以用一段简单的代码复现该问题：

public class Test {

    private static volatile long a = -1, b = -2;

    public static void main(String[] args) {
        long max = 1_000_000;
        new Thread(() -> {
            for (int i = 0; i < max; i++) {
                a = System.nanoTime();
            }
        }).start();
        new Thread(() -> {
            for (int i = 0; i < max; i++) {
                b = System.nanoTime();
            }
        }).start();
        for (int i = 0; i < max; i++) {
            if (a == b) {
                System.out.println("nanoTime not unique");
            }
        }
    }

}

阅读全文 »