Wiznet makers

최근 브라우저는 로컬 IP 주소에 대해서도 HTTPS를 우선 적용하는 동작을 보이고 있습니다. 이로 인해 기존 HTTP 기반 MCU WebServer는 정상 동작하더라도 브라우저 측에서 접속 오류가 발생하는 문제가 나타납니다. 본 아티클은 이러한 변화의 배경을 분석하고, 마이컨트롤러 환경에서 HTTPS를 구현하는 현실적인 방법들을 비교·정리합니다. 특히 소프트웨어 TLS(BearSSL) 방식과 하드웨어 보안 칩을 활용한 TLS 오프로딩 방식의 차이를 중심으로, Ethernet 기반 시스템에서의 설계 포인트를 설명합니다.

1. 배경: 왜 이제 MCU도 HTTPS가 필요한가

과거에는 로컬 네트워크에서 동작하는 장비의 Web UI가 HTTP만 지원해도 큰 문제가 없었습니다. 그러나 최근 Chromium 계열 브라우저(Brave 포함)는 다음과 같은 동작을 보입니다.

• 사용자가 http://192.168.x.x/ 페이지를 “현재 페이지로 등록”
• 이후 동일 페이지 접근 시 URL이 https://192.168.x.x/로 자동 변환
• MCU WebServer가 HTTPS를 지원하지 않으면 ERR_CONNECTION_REFUSED 발생

이 현상은 “외부 인터넷 서비스”가 아닌 로컬 장비에도 HTTPS 대응을 요구합니다. 단순 표시용 페이지가 아니라, 설정 정보나 인증 정보 등을 POST하는 구조라면 보안 요구는 더 이상 무시할 수 없습니다.

2. 프로젝트 목표

• MCU 기반 WebServer에서 HTTPS 제공 가능성 검증
• 브라우저 정책 변화에 대응 가능한 아키텍처 정리
• 로컬 장비 특성을 고려한 TLS 구현 방법 비교
• 외부 클라우드/서버 의존 없이 구현 가능한 보안 구조 탐색

3. HTTPS의 본질: TLS는 어디서 끝나는가

HTTPS 설계에서 가장 중요한 질문은 하나입니다.

TLS는 어느 디바이스에서 종료(termination)되는가?

이를 기준으로 MCU 환경의 HTTPS 구현은 세 가지로 분류됩니다.

4. 아키텍처 옵션 ①

Wi-Fi SoC가 TLS까지 처리하는 구조 (ESP32 / Pico W)

• TLS + HTTP Server를 SoC 내부에서 처리
• Arduino ESP32 / Arduino-Pico 환경에 SSL 예제 제공
• Pico W의 경우 BearSSL 기반 HTTPS 서버 예제 존재

장점

• 추가 부품 없이 HTTPS 구현 가능
• 구현 난이도 비교적 낮음

한계

• 인증서와 개인 키가 펌웨어 내부에 포함됨
• 키 유출 시 트래픽 복호화 가능
• 장기 운용·제품화에는 보안 설계가 취약

BearSSL 예제 자체에서도 “샘플 인증서는 실제 제품에 사용해서는 안 된다”고 명시하고 있습니다.

5. 아키텍처 옵션 ②

MCU가 소프트웨어 TLS를 직접 처리 (RP2040 + W5500)

• W5500은 TCP/IP까지 하드웨어 오프로딩
• TLS는 MCU에서 BearSSL 등으로 처리
• HTTPS 포트(443) 리슨 및 핸드셰이크를 MCU가 수행

기술적 조건

• TLS 서버 최소 요구:
  • 약 20KB Flash
  • 약 25KB RAM
• RP2040: 구현 가능 범위
• STM32F1(BluePill): RAM 제약으로 현실적 어려움

특징

• Ethernet 안정성 유지
• MCU 부하 증가
• 키/인증서 관리 책임이 MCU에 집중

6. 아키텍처 옵션 ③

보안 MCU/칩으로 TLS를 오프로딩 (W5500 + Secure Chip)

이 접근은 원문에서 가장 관심을 보인 방식입니다.

• Ethernet은 W5500이 담당
• TLS 핸드셰이크, 암복호화, 키 관리는 보안 칩이 담당
• MCU는 평문 HTTP 로직만 처리

예시:

• W5500 Ethernet Shield S
  • W5500 + MS1000 Secure MCU 구성
  • TLS 처리 및 키 보호를 하드웨어 레벨에서 수행

장점

• MCU RAM/Flash 부담 최소화
• 키가 외부로 노출되지 않음
• 장기 운용 및 제품화에 적합

주의사항

• MS1000 관련 정보는 2차 문서 기반
• 실제 설계 적용 시 공식 데이터시트 및 SDK 확인 필수

7. STM32 + W5500 + SSL 라이브러리에 대한 오해 정리

원문에서 언급된 EthernetWebServer_SSL_STM32 라이브러리는 다음과 같은 특징을 가집니다.

• SSL/TLS WebClient 기능 제공
• WebServer는 non-TLS
• 즉, HTTPS로 접속해오는 브라우저를 처리하는 서버 용도는 아님

따라서 이 라이브러리는:

• 외부 HTTPS API 호출 → 가능
• MCU가 HTTPS 서버 역할 수행 → 불가

이 구분은 매우 중요합니다.

8. 시스템 아키텍처 요약

9. WIZnet Insight

WIZnet의 W5500은 HTTPS를 직접 처리하지는 않지만, Ethernet + TCP/IP 오프로딩이라는 명확한 역할을 수행합니다. TLS를 MCU 또는 보안 칩으로 분리함으로써 다음과 같은 장점을 제공합니다.

• MCU 부하 감소
• 네트워크 안정성 확보
• TLS 구현 방식 선택의 자유도 확보

특히 Secure Chip과 결합한 구조는, 산업용·장기 운용 장비에서 요구되는 보안 신뢰성과 시스템 단순화를 동시에 달성할 수 있는 설계 포인트입니다.

10. 비즈니스 및 실사용 가치

• 브라우저 경고 없는 장비 Web UI 제공
• 로컬 장비에서도 보안 요구 충족
• 제품 수명 주기 동안 브라우저 정책 변화 대응 가능
• 설정 UI, NTP 서버, 관리 페이지 등 다양한 장비에 적용 가능

FAQ

Q1. 로컬 IP인데 HTTPS가 꼭 필요한가요?
A. 브라우저 동작 변화로 인해 “필요하게 되었습니다”. 기술 문제가 아니라 정책 문제입니다.

Q2. 자기서명 인증서로 충분한가요?
A. 기능적으로는 가능하지만, 키 보호 방식이 핵심입니다.

Q3. BluePill에서 HTTPS 서버는 불가능한가요?
A. 실무적으로는 매우 어렵습니다. RAM이 가장 큰 제약입니다.

Q4. 가장 현실적인 선택지는 무엇인가요?
A. 개발 단계에서는 ESP32/Pico W, 제품화 단계에서는 Secure Chip 오프로딩 구조가 합리적입니다.

Modern web browsers increasingly prioritize HTTPS, even for local IP addresses. As a result, microcontroller-based Web servers that only support HTTP may fail to load correctly, despite functioning as designed. This article analyzes the root cause of this issue and examines practical approaches to enabling HTTPS on embedded systems. In particular, it compares software-based TLS implementations with hardware-based TLS offloading, focusing on Ethernet-based MCU architectures.

1. Background: Why HTTPS Is Now Required for MCU Web Servers

Traditionally, HTTP-only Web interfaces were sufficient for devices operating on local networks. However, recent behavior observed in Chromium-based browsers (including Brave) shows a shift:

• A page accessed via http://192.168.x.x/ is bookmarked or registered
• The browser later rewrites the URL to https://192.168.x.x/
• If the MCU Web server does not support HTTPS, the browser reports ERR_CONNECTION_REFUSED

This change effectively forces even local embedded devices to support HTTPS. When Web interfaces accept configuration parameters or credentials via POST requests, the security implications become even more significant.

2. Project Objectives

• Evaluate the feasibility of HTTPS on MCU-based Web servers
• Analyze browser-driven requirements affecting embedded systems
• Compare realistic TLS implementation strategies
• Identify approaches that avoid dependence on external cloud services

3. The Core Question of HTTPS: Where Does TLS Terminate?

From a system design perspective, HTTPS boils down to a single critical question:

At which component is the TLS session terminated?

Based on this criterion, MCU-based HTTPS architectures can be classified into three categories.

4. Architecture Option 1

TLS Termination Inside a Wi-Fi SoC (ESP32 / Pico W)

• TLS and HTTP server run inside the Wi-Fi SoC
• SSL-enabled examples are available in ESP32 and Arduino-Pico environments
• Pico W provides BearSSL-based HTTPS server examples

Advantages

• No additional hardware required
• Relatively low implementation complexity

Limitations

• Private keys and certificates are embedded in firmware
• Key exposure compromises all encrypted traffic
• Not ideal for long-term or commercial deployment

Notably, the BearSSL examples themselves warn against using sample certificates in real products.

5. Architecture Option 2

Software TLS on the MCU (RP2040 + W5500)

• W5500 offloads Ethernet MAC and TCP/IP
• TLS is implemented in software on the MCU (e.g., BearSSL)
• MCU listens on port 443 and performs TLS handshakes

Technical Requirements

• Minimum TLS server footprint:
  • ~20 KB Flash
  • ~25 KB RAM
• RP2040-class MCUs: feasible
• STM32F1 (BluePill): impractical due to RAM limitations

Characteristics

• Retains Ethernet reliability
• Increases MCU memory and CPU load
• Key and certificate management remains software-based

6. Architecture Option 3

TLS Offloading to a Secure Chip (W5500 + Secure MCU)

This approach, strongly considered in the original project notes, separates security processing from the main MCU.

• W5500 handles Ethernet and TCP/IP
• A secure MCU or cryptographic chip manages:
  • TLS handshake
  • Encryption/decryption
  • Private key storage
• The main MCU processes only decrypted HTTP data

Example:

• W5500 Ethernet Shield S
  • Combines W5500 with an MS1000 secure MCU
  • Provides hardware-assisted TLS and protected key storage

Advantages

• Minimal MCU resource consumption
• Strong protection of private keys
• Suitable for industrial and long-life products

Caution

• MS1000 information is primarily based on secondary documentation
• Official datasheets and SDKs must be verified before production use

7. Common Misunderstanding: STM32 + W5500 + SSL Libraries

The referenced EthernetWebServer_SSL_STM32 library supports:

• TLS/SSL WebClient functionality
• Non-TLS WebServer operation

In other words:

• HTTPS client connections → supported
• MCU acting as an HTTPS server → not supported

This distinction is critical when evaluating HTTPS capabilities.

8. System Architecture Overview

9. WIZnet Insight

While the W5500 does not implement TLS itself, it provides robust hardware TCP/IP offloading that complements both software and hardware TLS strategies. By decoupling Ethernet networking from cryptographic processing, system designers gain:

• Reduced MCU workload
• Improved network stability
• Architectural flexibility in TLS implementation

When combined with a secure chip, this approach enables strong security while keeping the main application firmware simple and maintainable.

10. Practical and Business Value

• Browser-compatible, warning-free Web interfaces
• Compliance with evolving security expectations
• Reduced risk from future browser policy changes
• Applicable to configuration UIs, NTP servers, and device management pages

FAQ

Q1. Is HTTPS really necessary for local IP devices?
A. Yes. Browser behavior—not network topology—is now the determining factor.

Q2. Are self-signed certificates sufficient?
A. Functionally yes, but secure key storage is essential.

Q3. Can BluePill-class MCUs realistically host an HTTPS server?
A. In practice, no. RAM limitations are the primary barrier.

Q4. What is the most practical approach overall?
A. For development, ESP32 or Pico W. For production, TLS offloading using a secure chip is the most robust solution.